On Mon, Apr 8, 2024 at 10:12 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > I don't know that I'd call it scary exactly, but I do think it > was premature. A week ago there was no consensus that it was > ready to commit, but Alexander pushed it (or half of it, anyway) > despite that.
Some of the most compelling cases for the transformation will involve path keys. If the transformation enables the optimizer to build a plain index scan (or index-only scan) with useful path keys, then that might well lead to a far superior plan compared to what's possible with BitmapOrs. I understand that it'll still be possible to use OR expression evaluation in such cases, without applying the transformation (via filter quals), so in principle you don't need the transformation to get an index scan that can (say) terminate the scan early due to the presence of an "ORDER BY ... LIMIT n". But I suspect that that won't work out much of the time, because the planner will believe (rightly or wrongly) that the filter quals will incur too many heap page accesses. Another problem (at least as I see it) with the new or_to_any_transform_limit GUC is that its design seems to have nothing to say about the importance of these sorts of cases. Most of these cases will only have 2 or 3 constants, just because that's what's most common in general. -- Peter Geoghegan
