On Sat, May 11, 2024 at 3:19 PM Tom Lane wrote:
> showing that we are reading practically the whole index, which
> is pretty sad considering the index conditions are visibly
> mutually contradictory. What's going on? I find that:
>
> 1. _bt_preprocess_keys, which is responsible for detecting
> m
On Sat, May 11, 2024 at 4:12 PM Peter Geoghegan 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 s
On Sat, May 11, 2024 at 5:05 PM Tom Lane wrote:
> Hmm, I'm generally in favor of a lot of small patches rather than one
> enormously complex one. Isn't this point something that could be
> broken out?
That's not really possible here.
Skip scan generally works by consing up a special "skip" arra
Peter Geoghegan writes:
> On Sat, May 11, 2024 at 4:21 PM Tom Lane wrote:
>>> 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_prepr
On Sat, May 11, 2024 at 4:12 PM Peter Geoghegan 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
On Sat, May 11, 2024 at 4:21 PM Tom Lane 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
Peter Geoghegan writes:
> On Sat, May 11, 2024 at 3:19 PM Tom Lane 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 depe
On Sat, May 11, 2024 at 3:19 PM Tom Lane wrote:
> This produces something like
>
> Index Only Scan using my_idx on t (cost=0.43..8.46 rows=1 width=8) (actual
> time=475.713..475.713 rows=0 loops=1)
>Index Cond: ((ROW(a, b) > ROW(123450, 123444)) AND (a = 0))
>Heap Fetches: 0
>Buffer
