Re: POC, WIP: OR-clause support for indexes - Mailing list pgsql-hackers

From Alena Rybakina
Subject Re: POC, WIP: OR-clause support for indexes
Date
Msg-id 3ec856b1-51bd-9b5e-e644-6831a8a1df7c@yandex.ru
Whole thread Raw
In response to Re: POC, WIP: OR-clause support for indexes  (Andrey Lepikhov <a.lepikhov@postgrespro.ru>)
Responses Re: POC, WIP: OR-clause support for indexes
List pgsql-hackers
Hi!

On 11.07.2023 11:47, Andrey Lepikhov wrote:
> This patch looks much better than earlier. But it definitely needs 
> some covering with tests. As a first simple approximation, here you 
> can see the result of regression tests, where the transformation limit 
> is set to 0. See in the attachment some test changes induced by these 
> diffs.
>
Yes, I think so too. I also added some tests. I have attached an 
additional diff-5.diff where you can see the changes.
> Also, I see some impact of the transformation to other queries:
> create_view.out:
> (NOT x > z) ----> (x <= z)
> inherit.out:
> (((a)::text = 'ab'::text) OR ((a)::text = ANY ('{NULL,cd}'::text[])))
> to -
> (((a)::text = ANY ('{NULL,cd}'::text[])) OR ((a)::text = 'ab'::text))
>
> Transformations, mentioned above, are correct, of course. But it can 
> be a sign of possible unstable behavior.
>
I think it can be made more stable if we always add the existing 
transformed expressions first, and then the original ones, or vice versa. T

o do this, we will need two more lists, I think, and then we can combine 
them, where the elements of the second will be written to the end of the 
first.

But I suppose that this may not be the only unstable behavior - I 
suppose we need sorting result elements on the left side, what do you think?

-- 
Regards,
Alena Rybakina
Postgres Professional

Attachment

pgsql-hackers by date:

Previous
From: Alexander Lakhin
Date:
Subject: Re: stats test intermittent failure
Next
From: Alvaro Herrera
Date:
Subject: Re: tablecmds.c/MergeAttributes() cleanup