Re: Replace IN VALUES with ANY in WHERE clauses during optimization
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Alena Rybakina <a.rybakina@postgrespro.ru>,
Ivan Kush <ivan.kush@tantorlabs.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-10-03T21:08:28Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Stabilize regression test from c0962a113.
- 3ba2cdaa4541 18.0 landed
-
Convert 'x IN (VALUES ...)' to 'x = ANY ...' then appropriate
- c0962a113d1f 18.0 landed
-
Extract make_SAOP_expr() function from match_orclause_to_indexcol()
- d48d2e2dc8be 18.0 landed
Laurenz Albe <laurenz.albe@cybertec.at> writes: > I wonder if it is worth the extra planning time to detect and improve > such queries. I'm skeptical too. I'm *very* skeptical of implementing it in the grammar as shown here --- I'd go so far as to say that that approach cannot be accepted. That's far too early, and it risks all sorts of problems. An example is that the code as given seems to assume that all the sublists are the same length ... but we haven't checked that yet. I also suspect that this does not behave the same as the original construct for purposes like resolving dissimilar types in the VALUES list. (In an ideal world, perhaps it'd behave the same, but that ship sailed a couple decades ago.) regards, tom lane