Re: Is the plan for IN(1,2,3) always the same as for =ANY('{1,2,3}') when using PQexec with no params?
От | Tom Lane |
---|---|
Тема | Re: Is the plan for IN(1,2,3) always the same as for =ANY('{1,2,3}') when using PQexec with no params? |
Дата | |
Msg-id | 1761901.1668657080@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Is the plan for IN(1,2,3) always the same as for =ANY('{1,2,3}') when using PQexec with no params? (Dmitry Koterov <dmitry.koterov@gmail.com>) |
Ответы |
Re: Is the plan for IN(1,2,3) always the same as for =ANY('{1,2,3}') when using PQexec with no params?
|
Список | pgsql-hackers |
Dmitry Koterov <dmitry.koterov@gmail.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
В списке pgsql-hackers по дате отправления: