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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: SHA-2 functions
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Allow workers to override datallowconn