Re: POC, WIP: OR-clause support for indexes
От | Alena Rybakina |
---|---|
Тема | Re: POC, WIP: OR-clause support for indexes |
Дата | |
Msg-id | 3ec856b1-51bd-9b5e-e644-6831a8a1df7c@yandex.ru обсуждение исходный текст |
Ответ на | Re: POC, WIP: OR-clause support for indexes (Andrey Lepikhov <a.lepikhov@postgrespro.ru>) |
Ответы |
Re: POC, WIP: OR-clause support for indexes
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: