Re: POC, WIP: OR-clause support for indexes
От | Andrei Lepikhov |
---|---|
Тема | Re: POC, WIP: OR-clause support for indexes |
Дата | |
Msg-id | 65bfdcb6-0f0c-4d4c-a721-cb38a0ba91c7@postgrespro.ru обсуждение исходный текст |
Ответ на | POC, WIP: OR-clause support for indexes (Teodor Sigaev <teodor@sigaev.ru>) |
Список | pgsql-hackers |
On 21/8/2024 02:17, Alexander Korotkov wrote: > Also, I convert the check you've introduced in the previous message to > op_in_opfamily(), and introduced collation check similar to > match_opclause_to_indexcol(). Hi, I passed through the patches with fresh sight. Conceptually, this approach looks much better than the previous series. Just for the record: previously, we attempted to resolve two issues in one - improve the execution plan and save cycles during the optimisation. As I see it, it is almost impossible in this feature. So, I should come to terms with carrying long OR lists through the planning and the additional overhead this feature generates. I also see that the optimiser has obtained additional planning strategies with these patches and hasn't lost any. Couple of findings: First: /* Only operator clauses scan match */ Should it be: /* Only operator clauses can match */ ? The second one: When creating IndexClause, we assign the original and derived clauses to the new, containing transformed array. But logically, we should set the clause with a list of ORs as the original. Why did you do so? -- regards, Andrei Lepikhov Postgres Professional
В списке pgsql-hackers по дате отправления: