From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Dmitry Koterov <dmitry(dot)koterov(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Is the plan for IN(1,2,3) always the same as for =ANY('{1,2,3}') when using PQexec with no params? |
Date: | 2022-11-17 03:51:20 |
Message-ID: | 1761901.1668657080@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Dmitry Koterov <dmitry(dot)koterov(at)gmail(dot)com> writes:
> PG13+. Assume we have two identical queries with no arguments (as a plain
> text, e.g. passed to PQexec - NOT to PQexecParams!):
> - one with "a=X AND b IN(...)"
> - and one with "a=X and b=ANY('{...}')
> The question: is it guaranteed that the planner will always choose
> identical plans for them (or, at least, the plan for ANY will not match an
> existing index worse than the plan with IN)?
This depends greatly on what "..." represents. But if it's a list
of constants, they're probably equivalent. transformAExprIn()
offers some caveats:
* We try to generate a ScalarArrayOpExpr from IN/NOT IN, but this is only
* possible if there is a suitable array type available. If not, we fall
* back to a boolean condition tree with multiple copies of the lefthand
* expression. Also, any IN-list items that contain Vars are handled as
* separate boolean conditions, because that gives the planner more scope
* for optimization on such clauses.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Himanshu Upadhyaya | 2022-11-17 03:57:19 | Re: HOT chain validation in verify_heapam() |
Previous Message | Andres Freund | 2022-11-17 03:48:14 | Re: CI and test improvements |