Re: POC, WIP: OR-clause support for indexes

From: Alena Rybakina <a(dot)rybakina(at)postgrespro(dot)ru>
To: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Peter Geoghegan <pg(at)bowt(dot)ie>, Robert Haas <robertmhaas(at)gmail(dot)com>, "Finnerty, Jim" <jfinnert(at)amazon(dot)com>, Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>, Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, teodor(at)sigaev(dot)ru, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: POC, WIP: OR-clause support for indexes
Date: 2023-11-28 03:52:20
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 25.11.2023 19:13, Alexander Korotkov wrote:
> On Sat, Nov 25, 2023 at 1:10 PM Alena Rybakina
> <a(dot)rybakina(at)postgrespro(dot)ru> wrote:
>> On 25.11.2023 04:13, Alexander Korotkov wrote:
>> It seems to me there is a confusion. I didn't mean we need to move
>> conversion of OR-expressions to ANY into choose_bitmap_and() function
>> or anything like this. My idea was to avoid degradation of plans,
>> which I've seen in [1]. Current code for generation of bitmap paths
>> considers the possibility to split OR-expressions into distinct bitmap
>> index scans. But it doesn't consider this possibility for
>> ANY-expressions. So, my idea was to enhance our bitmap scan
>> generation to consider split values of ANY-expressions into distinct
>> bitmap index scans. So, in the example [1] and similar queries
>> conversion of OR-expressions to ANY wouldn't affect the generation of
>> bitmap paths.
>> Thanks for the explanation, yes, I did not understand the idea correctly at first. I will try to implement something similar.
> Alena, great, thank you. I'm looking forward to the updated patch.
I wrote the patch (any_to_or.diff.txt), although it is still under
development (not all regression tests have been successful so far), it
is already clear that for a query where a bad plan was chosen before, it
is now choosing a more optimal query plan.

postgres=# set enable_or_transformation =on;
postgres=# explain select * from test where (x = 1 or x = 2) and y = 100;
                                                  QUERY PLAN
 Bitmap Heap Scan on test  (cost=8.60..12.62 rows=1 width=12)
   Recheck Cond: (((y = '100'::double precision) AND (x = 1)) OR ((y =
'100'::double precision) AND (x = 2)))
   ->  BitmapOr  (cost=8.60..8.60 rows=1 width=0)
         ->  Bitmap Index Scan on test_x_1_y  (cost=0.00..4.30 rows=1
               Index Cond: (y = '100'::double precision)
         ->  Bitmap Index Scan on test_x_2_y  (cost=0.00..4.30 rows=1
               Index Cond: (y = '100'::double precision)
(7 rows)

While I'm thinking how to combine it now.

BTW, while I was figuring out how create_index_paths works and creating
bitmapscan indexes, I think I found a bug with unallocated memory (fix
patch is bugfix.diff.txt). Without a fix here, it falls into the crust
at the stage of assigning a value to any of the variables, specifically,
skip_lower_stop and skip_nonnative_saop. I discovered it when I forced
to form a bitmapindex plan for ANY (any_to_or.diff.txt). I'm causing a
problem with my OR->ANY conversion patch.

Alena Rybakina
Postgres Professional

Attachment Content-Type Size
cause_problem.diff.txt text/plain 1.9 KB
bugfix.diff.txt text/plain 511 bytes
any_to_or.diff.txt text/plain 6.3 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-11-28 03:55:37 Re: SSL tests fail on OpenSSL v3.2.0
Previous Message Michael Paquier 2023-11-28 03:47:03 Re: SSL tests fail on OpenSSL v3.2.0