Re: apply_scanjoin_target_to_paths and partitionwise join

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Arne Roland <arne(dot)roland(at)malkut(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Andrei Lepikhov <lepihov(at)gmail(dot)com>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, 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: 2025-10-29 12:47:45
Message-ID: CA+TgmoZvGSb_fi=tB8kia9FoFcPka7-7htWV-3DN=MZeFVzdyA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 29, 2025 at 6:43 AM Arne Roland <arne(dot)roland(at)malkut(dot)net> wrote:
> Richard already covered a lot. I mainly want to reiterate, that a public test case would be immensely helpful.

I agree, and said the same.

> The Q1 you mentioned sadly isn't a real test case, where I can measure performance impact. More an academic difference in costs, which I don't fully comprehend as of now.

I don't either, but maybe if I study it (or you or someone else does)
we can begin to comprehend it.

> Did you encounter a case a in production, that made you reevaluate this thread? If so a public reproducer would be very appreciated.

No, what happened is that this broke a patch I'm working on. The
details are lengthy and would take us too far away from the topic of
this thread, but the highly-compressed version is that I spent about
six hours going "wait, why the heck isn't this working?" and
eventually traced it back to the pathlist for a partitionwise join
getting zapped. I might have to bolt on some kind of a fix to un-break
that patch for now, but it's not relevant in terms of constructing a
reproducer for this problem. I think the best shot at coming up with a
reproducer here is to study the cost differences in the queries where
the plan changes with the fix, particularly Q1 from my prior email.
While I agree with you that at present that is just a numerical effect
and not a real performance effect, we don't even have an explanation
for how the numerical effect is possible. It seems like a good idea to
figure that out.

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Euler Taveira 2025-10-29 12:53:16 Re: [PATCH] Add Windows support for backtrace_functions (MSVC only)
Previous Message Robert Haas 2025-10-29 12:36:05 Re: apply_scanjoin_target_to_paths and partitionwise join