Message-ID: <c0a1d57a-1f66-4073-a1c1-9240f18a4baa@gmail.com>
Date: Fri, 28 Mar 2025 13:15:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: POC, WIP: OR-clause support for indexes
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Alena Rybakina <a.rybakina@postgrespro.ru>,
 Pavel Borisov <pashkin.elfe@gmail.com>,
 Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers@lists.postgresql.org
References: <567ED6CA.2040504@sigaev.ru>
 <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>
 <0db3c58a-0336-456b-8ae9-a8e5154ee7a5@gmail.com>
 <CAPpHfdv1fgDX0kse=wCFs5Va_5iJA3CMyuZU2tjsCzdnagYg5Q@mail.gmail.com>
Content-Language: en-AU
From: Andrei Lepikhov <lepihov@gmail.com>
In-Reply-To: 
 <CAPpHfdv1fgDX0kse=wCFs5Va_5iJA3CMyuZU2tjsCzdnagYg5Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/c0a1d57a-1f66-4073-a1c1-9240f18a4baa%40gmail.com>
Precedence: bulk

On 3/28/25 12:59, Alexander Korotkov wrote:
> On Fri, Mar 28, 2025 at 1:32 PM Andrei Lepikhov <lepihov@gmail.com> wrote:
> I don't think this is going to be CPU-consuming.  I don't think this
> is going to be measurable.  This patch introduces one additional pass
> over array of OrArgIndexMatch'es, and qsort of them.  I think I've
> seen places where we spend quadratic time over the number of
> OR-clauses.  Even calls of match_index_to_operand() for every clause
> and every index look way more expensive.
Ok, I have no more objections.

> I think my patch gives better determinism too.  For instance, output
> order doesn't depend on order of indexes in rel->indexlist.
Nice!

-- 
regards, Andrei Lepikhov