On Thu, Jul 25, 2024 at 5:04 PM Alena Rybakina
<a.rybakina@postgrespro.ru> wrote:
> To be honest, I have found a big problem in this patch - we try to perform the transformation every time we examime a
column:
>
> for (indexcol = 0; indexcol < index->nkeycolumns; indexcol++) { ...
>
> }
>
> I have fixed it and moved the transformation before going through the loop.
What makes you think there is a problem? Do you have a test case
illustrating a slow planning time?
When v27 performs transformation for a particular column, it just
stops facing the first unmatched OR entry. So,
match_orclause_to_indexcol() examines just the first OR entry for all
the columns excepts at most one. So, the check
match_orclause_to_indexcol() does is not much slower than other
match_*_to_indexcol() do.
I actually think this could help performance in many cases, not hurt
it. At least we get rid of O(n^2) complexity over the number of OR
entries, which could be very many.
------
Regards,
Alexander Korotkov
Supabase
