Re: apply_scanjoin_target_to_paths and partitionwise join

From: Andrei Lepikhov <lepihov(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
Cc: Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, arne(dot)roland(at)malkut(dot)net, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, Richard Guo <guofenglinux(at)gmail(dot)com>
Subject: Re: apply_scanjoin_target_to_paths and partitionwise join
Date: 2024-09-30 21:52:11
Message-ID: c55907c5-8b1d-42a5-8bb5-b4c9d92c993f@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 24/7/2024 15:22, Ashutosh Bapat wrote:
> On Wed, Jul 24, 2024 at 9:42 AM Richard Guo <guofenglinux(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-09-30 22:01:11 Re: pg_verifybackup: TAR format backup verification
Previous Message v.popolitov 2024-09-30 21:30:40 Re: Increase of maintenance_work_mem limit in 64-bit Windows