Re: apply_scanjoin_target_to_paths and partitionwise join
От | Andrei Lepikhov |
---|---|
Тема | Re: apply_scanjoin_target_to_paths and partitionwise join |
Дата | |
Msg-id | c55907c5-8b1d-42a5-8bb5-b4c9d92c993f@gmail.com обсуждение исходный текст |
Ответ на | Re: apply_scanjoin_target_to_paths and partitionwise join (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>) |
Ответы |
Re: apply_scanjoin_target_to_paths and partitionwise join
|
Список | pgsql-hackers |
On 24/7/2024 15:22, Ashutosh Bapat wrote: > On Wed, Jul 24, 2024 at 9:42 AM Richard Guo <guofenglinux@gmail.com> wrote: >> Is there a specific query that demonstrates benefits from this change? >> I'm curious about scenarios where a partitionwise join runs slower >> than a non-partitionwise join. > > [1] provides a testcase where a nonpartitionwise join is better than > partitionwise join. This testcase is derived from a bug reported by an > EDB customer. [2] is another bug report on psql-bugs. I haven't passed through the patch yet, but can this issue affect the decision on what to push down to foreign servers: a whole join or just a scan of two partitions? If the patch is related to the pushdown decision, I'd say it is quite an annoying problem for me. From time to time, I see cases where JOIN produces more tuples than both partitions have in total - in this case, it would be better to transfer tables' tuples to the main instance before joining them. -- regards, Andrei Lepikhov
В списке pgsql-hackers по дате отправления: