Re: [HACKERS] PoC: full merge join on comparison clause
От | Alexander Kuzmenkov |
---|---|
Тема | Re: [HACKERS] PoC: full merge join on comparison clause |
Дата | |
Msg-id | 513df2b9-b068-6cf4-895e-adb3968547e0@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: [HACKERS] PoC: full merge join on comparison clause (Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>) |
Ответы |
Re: [HACKERS] PoC: full merge join on comparison clause
|
Список | pgsql-hackers |
Here are some updates on this patch. I split it into two parts. The preparatory part contains some mechanical changes to prepare for the main part. Most importantly, a new field is added, `RestrictInfo.is_mj_equality`. It is a marker of mergejoinable equality clauses, and `RestrictInfo.mergeopfamilies` is a more general marker of clauses that are mergejoinable but not necessarily equality. The usages are changed accordingly. The main part consists of executor and planner changes required to support inequality merge joins. The executor changes are as described in the original post. The planner part has changed significantly since the last version. It used to apply some shady hacks to ensure we have the required sort orders of inner and outer paths. Now I think I found a reasonable way to generate the pathkeys we need. When we sort outer relation in `sort_inner_and_outer()`, the pathkeys are generated by `select_outer_pathkeys_for_merge()`. When we use the pathkeys we already have for the outer relation in `match_unsorted_outer()`, mergeclauses are selected by `find_mergeclauses_for_pathkeys()`. I changed these functions to select the right pathkey direction for merge clauses, and also ensure that we only have a single inequality merge clause and it is the last one. Also, to use the index paths, I changed `pathkeys_useful_for_merging()` to keep both pathkey directions for inequality merge clauses. Some basic joins work, but I couldn't properly test all the corner cases with different orderings, because they depend on a bug in vanilla merge joins [1]. To sum up, the preparatory and executor changes are stable, and the planner part is WIP. 1. https://www.postgresql.org/message-id/flat/5dad9160-4632-0e47-e120-8e2082000c01@postgrespro.ru -- Alexander Kuzmenkov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Вложения
В списке pgsql-hackers по дате отправления: