Re: apply_scanjoin_target_to_paths and partitionwise join

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: 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>, arne(dot)roland(at)malkut(dot)net, 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-01-02 20:58:24
Message-ID: 303774.1735851504@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I'm obviously missing something here, because I'm sure Jakub is quite
> right when he says that this actually happened and actually hosed an
> EDB customer. But I don't understand HOW it happened, and I think if
> we're going to change the code we really ought to understand that and
> write some code comments about it. In general, I think that it's very
> reasonable to expect that a bunch of small joins will beat one big
> join, which is why the code does what it currently does.

I am wondering if the problem is not that the plan is slower, it's
that for some reason the planner took a lot longer to create it.
It's very plausible that partitionwise planning takes longer, and
maybe we have some corner cases where the time is O(N^2) or worse.

However, this is pure speculation without a test case, and any
proposed fix would be even more speculative. I concur with your
bottom line: we should insist on a public test case before deciding
what to do about it.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2025-01-02 21:09:04 Re: Add the ability to limit the amount of memory that can be allocated to backends.
Previous Message Bruce Momjian 2025-01-02 20:50:43 Re: Fwd: Re: A new look at old NFS readdir() problems?