Hebben alle groepen dezelfde totale macht voor een bepaalde subgroep?

Lees de vraag aandachtig

En:

Het belangrijkste punt voor prestaties is om irrelevante rijen vroegtijdig uit te sluiten en alleen aggregaten te berekenen voor de gegeven subgroep . Dan (ervan uitgaande dat er meer dan een paar verschillende subgroepen zijn), een index op (subgroup) kan helpen:

CREATE INDEX ON foo (subgroup);

Elk van de volgende zoekopdrachten retourneert FALSE als ten minste twee groepen verschillende totaalsommen hebben voor de gegeven subgroep, en TRUE in alle andere gevallen (met een kleine uitzondering voor vraag 5, zie hieronder).

Vraag 1

SELECT count(DISTINCT total_power) = 1
FROM  (
   SELECT sum(power) AS total_power
   FROM   foo
   WHERE  subgroup = 'Sub_B'  -- exclude irrelevant rows early!
   GROUP  BY grp
   ) sub;

Vraag 2

SELECT count(*) = 1
FROM  (
   SELECT true
   FROM  (
      SELECT sum(power) AS total_power
      FROM   foo
      WHERE  subgroup = 'Sub_C'
      GROUP  BY grp
      ) sub2
   GROUP  BY total_power
   ) sub2;

Vraag 3

SELECT count(*) OVER () = 1
FROM  (
   SELECT sum(power) AS total_power
   FROM   foo
   WHERE  subgroup = 'Sub_A'
   GROUP  BY grp
   ) sub
GROUP  BY total_power
LIMIT  1;

Vraag 4

(
SELECT FALSE
FROM  (
   SELECT sum(power) AS total_power
   FROM   foo
   WHERE  subgroup = 'Sub_A'
   GROUP  BY grp
   ) sub
GROUP  BY total_power
OFFSET 1
LIMIT  1
)
UNION ALL
SELECT TRUE
LIMIT 1;

Deze is speciaal. Gerelateerde antwoorden met uitleg:

• Retourneer een waarde als er geen record wordt gevonden
• Manier om meerdere SELECT's te proberen totdat een resultaat beschikbaar is?

Vraag 5

SELECT min(total_power) = max(total_power)  -- can fail for NULL values
FROM  (
   SELECT sum(power) AS total_power
   FROM   foo
   WHERE  subgroup = 'Sub_A'
   GROUP  BY grp
   ) sub;

De laatste kan mislukken als NULL waarden in de macht zijn toegestaan. (Maar u zou in dit geval toch de verwachte resultaten moeten definiëren.)

Ik heb een uitgebreide test uitgevoerd en vond dat alle zoekopdrachten onder ideale omstandigheden ongeveer hetzelfde deden:

db<>fiddle hier

Query 5 was meestal een beetje sneller dan de rest.