Re: apply_scanjoin_target_to_paths and partitionwise join
От | Richard Guo |
---|---|
Тема | Re: apply_scanjoin_target_to_paths and partitionwise join |
Дата | |
Msg-id | CAMbWs48U9EqUtaDeC0dAbQgFTd_L0Zazfv5L2Y1__O=PE+TwsQ@mail.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 Wed, May 22, 2024 at 3:57 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote: > I will create patches for the back-branches once the patch for master is in a committable state. AFAIU, this patch prevents apply_scanjoin_target_to_paths() from discarding old paths of partitioned joinrels. Therefore, we can retain non-partitionwise join paths if the cheapest path happens to be among them. One concern from me is that if the cheapest path of a joinrel is a partitionwise join path, following this approach could lead to undesirable cross-platform plan variations, as detailed in the original comment. 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. Thanks Richard
В списке pgsql-hackers по дате отправления: