Lisez attentivement la question
Et :
Le point important pour les performances est d'exclure tôt les lignes non pertinentes et de calculer uniquement les agrégats pour le sous-groupe donné . Ensuite (en supposant plus de quelques sous-groupes distincts), un index sur (subgroup)
peut aider :
CREATE INDEX ON foo (subgroup);
Chacune des requêtes suivantes renvoie FALSE
si au moins deux groupes ont des sommes totales différentes pour le sous-groupe donné, et TRUE
en tous autres cas (avec une exception mineure pour la requête 5, voir ci-dessous).
Requête 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;
Requête 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;
Requête 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;
Requête 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;
Celui-ci est spécial. Réponses associées avec explication :
- Renvoyer un valeur si aucun enregistrement n'est trouvé
- Comment essayer plusieurs SELECT jusqu'à ce qu'un résultat soit disponible ?
Requête 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;
Le dernier peut échouer si NULL
les valeurs en puissance sont autorisées. (Mais vous devrez quand même définir les résultats attendus dans ce cas.)
J'ai effectué un test approfondi et trouvé que toutes les requêtes s'exécutaient à peu près de la même façon dans des conditions idéales :
db<>violon ici
La requête 5 avait tendance à être un peu plus rapide que les autres.