Je pense que OFFSET 0 est la meilleure approche car il s'agit plus évidemment d'un hack montrant que quelque chose de bizarre se passe, et il est peu probable que nous modifiions jamais le comportement de l'optimiseur autour de OFFSET 0 ... tandis que espérons que les CTE deviendront inlineables à un moment donné Les CTE sont devenus inlineables par défaut dans PostgreSQL 12. L'explication suivante est par souci d'exhaustivité; utilisez la réponse de Seamus.
Pour les sous-requêtes non corrélées, vous pourriez exploiter le refus de PostgreSQL 11 et versions antérieures d'intégrer WITH termes de requête pour reformuler votre requête comme :
WITH t AS (
SELECT * FROM tbl WHERE id IN ('6d48fc431d21', 'd9e659e756ad')
)
SELECT COUNT(*)
FROM t
WHERE data ? 'building_floorspace'
AND data ?| ARRAY['elec_mean_monthly_use', 'gas_mean_monthly_use'];
Cela a à peu près le même effet que le OFFSET 0 hack, et comme le offset 0 hack exploite les bizarreries de l'optimiseur de Pg que les gens utilisent pour contourner le manque d'indices de requête de Pg... en les utilisant comme indices de requête.
Mais le OFFSET 0 hack est quelque peu officiellement béni, alors que l'abus CTE ne fonctionne plus dans PostgreSQL 12. (Yay !).
