From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>, Ivan Kush <ivan(dot)kush(at)tantorlabs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Replace IN VALUES with ANY in WHERE clauses during optimization |
Date: | 2024-10-03 21:08:28 |
Message-ID: | 461998.1727989708@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Nathan Bossart | 2024-10-03 21:13:41 | Re: Enable data checksums by default |
Previous Message | Laurenz Albe | 2024-10-03 20:19:56 | Re: Replace IN VALUES with ANY in WHERE clauses during optimization |