Re: Inefficient nbtree behavior with row-comparison quals - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Inefficient nbtree behavior with row-comparison quals
Date
Msg-id CAH2-WznFwrQ52TMMuUWPQ1uvHpkQzB3ZKrBuSgGcfw=+ygh3hw@mail.gmail.com
Whole thread Raw
In response to Re: Inefficient nbtree behavior with row-comparison quals  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Sat, May 11, 2024 at 4:12 PM Peter Geoghegan <pg@bowt.ie> wrote:
> 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. After all, there is no indirection to disambiguate
> which array belongs to which scan key.

Minor correction: there is an indirection. We can get from any
BTArrayKeyInfo entry to its so->arrayData[] scan key using the
BTArrayKeyInfo.scan_key offset. It'd just be inconvenient to do it
that way around within _bt_advance_array_keys, since
_bt_advance_array_keys's loop iterates through so->arrayData[] in the
usual order (just like in _bt_check_compare).

There is an assertion within _bt_advance_array_keys (and a couple of
other similar assertions elsewhere) that verify that everybody got it
right, though. The "Assert(array->scan_key == ikey);" assertion. So if
_bt_preprocess_keys ever violated the expectations held by
_bt_advance_array_keys, the problem would probably be detected before
long.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: SQL:2011 application time
Next
From: Paul Jungwirth
Date:
Subject: Re: SQL:2011 application time