From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Inefficient nbtree behavior with row-comparison quals |
Date: | 2024-05-11 20:21:36 |
Message-ID: | 80384.1715458896@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Geoghegan <pg(at)bowt(dot)ie> writes:
> On Sat, May 11, 2024 at 3:19 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> However, despite the rather over-the-top verbosity of commenting in
>> _bt_advance_array_keys, it's far from clear why or how it depends on
>> that. So I feel a little stuck about what needs to be done here.
> The dependency is fairly simple. In the presence of multiple arrays on
> the same column, which must be contradictory/redundant, but cannot be
> simplified solely due to lack of suitable cross-type support, we have
> multiple arrays on the same index column. _bt_advance_array_keys wants
> to deal with this by assuming that the scan key order matches the
> array key order.
I guess what is not clear to me is what you mean by "array key order".
Is that simply the order of entries in BTArrayKeyInfo[], or are there
additional assumptions/restrictions?
> There's another problem along these lines, that seems at least as bad:
> queries involving contradictory >= and <= quals aren't recognized as
> contradictory during preprocessing. There's no reason why
> _bt_preprocessing_keys couldn't detect that case; it just doesn't
> right now.
Ugh, how'd we miss that? I can take a look at this, unless you're
on it already.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2024-05-11 20:30:48 | Re: Inefficient nbtree behavior with row-comparison quals |
Previous Message | Peter Geoghegan | 2024-05-11 20:12:18 | Re: Inefficient nbtree behavior with row-comparison quals |