Message-ID: <0db3c58a-0336-456b-8ae9-a8e5154ee7a5@gmail.com>
Date: Fri, 28 Mar 2025 12:32:51 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: POC, WIP: OR-clause support for indexes
To: Alexander Korotkov <aekorotkov@gmail.com>,
 Alena Rybakina <a.rybakina@postgrespro.ru>
Cc: Pavel Borisov <pashkin.elfe@gmail.com>,
 Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers@lists.postgresql.org
References: <567ED6CA.2040504@sigaev.ru>
 <CAPpHfdtgcye9ELaLHw4ZOUxWQ9t1P=oBDJX8KwwOHqasESdXQQ@mail.gmail.com>
 <CAPpHfdv+jtNwofg-p5z86jLYZUTt6tR17Wy00ta0dL=wHQN3ZA@mail.gmail.com>
 <ab8aedce-7a2f-4bb2-bfad-3f1ad91e7336@gmail.com>
 <41ba3d47-2a48-476c-88d4-6ebd889a7af2@gmail.com>
 <CAPpHfdvehQbCpQG9zYr739y2nXQkE=FYsat5VE-pDoB4RDPfBw@mail.gmail.com>
 <e40494ad-cad8-43e6-8372-d0c7b3411ad7@postgrespro.ru>
 <CAPpHfdtPz+J-n6=qAMBqx1p88Ut_cbS9JRbL+EKRpWY04tGcRg@mail.gmail.com>
 <036d64e6-4d47-485c-b047-6664d452b3e8@postgrespro.ru>
 <CAPpHfdumgFuUihGqrmDVR5FnzOLsAah-ZdZ269FgsUrOeNU6rw@mail.gmail.com>
 <1a4f1631-86c1-4185-a520-03b24a389449@postgrespro.ru>
 <CALT9ZEE94JN01za2o872foQErgyLHaX7OnOtoh70QbmXP7=S2A@mail.gmail.com>
 <3ac7c436-81e1-4191-9caf-b0dd70b51511@gmail.com>
 <CALT9ZEEyivV=CDE=CCf8JwT5dU2epBDmbiRyVg8fO7-m6rud7g@mail.gmail.com>
 <72eab2bf-7f94-4f58-84bc-2b80d74b6443@postgrespro.ru>
 <CAPpHfdu71LCrXfwaRot1u_xfx7r92VFvZNRLvQJS79B3XFmBhg@mail.gmail.com>
Content-Language: en-AU
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: 
 <CAPpHfdu71LCrXfwaRot1u_xfx7r92VFvZNRLvQJS79B3XFmBhg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/0db3c58a-0336-456b-8ae9-a8e5154ee7a5%40gmail.com>
Precedence: bulk

On 3/28/25 00:18, Alexander Korotkov wrote:
> The attached patch changes the reordering algorithm of
> group_similar_or_args() in the following way.  We reorder each group
> of similar clauses so that the first item of the group stays in place,
> but all the other items are moved after it.  So, if there are no
> similar clauses, the order of clauses stays the same.  When there are
> some groups, only required reordering happens while the rest of the
> clauses remain in their places.
The patch looks good to me from a technical perspective. But it seems 
like an overkill, isn't it?
You introduce additional CPU-consuming operations in the planning OR 
operations.
My point is: 1) as Pavel has mentioned, Postgres doesn't guarantee the 
evaluation/output order of the clauses at all. 2) we need that to keep 
regression tests stable (don't forget extensions' and forks' developers 
too). But it should be done once if we have no fluidity in OR clauses 
order in general.
The trade-off with tricky query writers and regression tests may be 
preserving the order until OR->ANY has happened. If it has happened, 
just ensure the order is determined somehow. Except that, any other 
spending on CPU cycles seems too expensive.

-- 
regards, Andrei Lepikhov