Re: Inefficient nbtree behavior with row-comparison quals

On Sat, May 11, 2024 at 4:12 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> Row comparisons are kind of a special case, both during preprocessing
> and during the scan itself. I find it natural to blame this problem on
> the fact that preprocessing makes exactly zero effort to detect
> contradictory conditions that happen to involve a RowCompare. Making
> non-zero effort in that direction would already be a big improvement.

BTW, I'm playing with the idea of eliminating the special case logic
around row comparisons scan keys through smarter preprocessing, of the
kind that the MDAM paper contemplates for the SQL standard row
constructor syntax (under its "Multi-Valued Predicates" section). I'm
not sure if I'll get around to that anytime soon, but that sort of
approach seems to have a lot to recommend it. Maybe nbtree shouldn't
even have to think about row comparisons, except perhaps during
preprocessing. (Actually, nbtree already doesn't have to deal with
equality row comparisons -- this scheme would mean that it wouldn't
have to deal with row comparison inequalities.)

--
Peter Geoghegan