Re: apply_scanjoin_target_to_paths and partitionwise join - Mailing list pgsql-hackers

From Tom Lane
Subject Re: apply_scanjoin_target_to_paths and partitionwise join
Date
Msg-id 303774.1735851504@sss.pgh.pa.us
Whole thread Raw
In response to Re: apply_scanjoin_target_to_paths and partitionwise join  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: apply_scanjoin_target_to_paths and partitionwise join
List pgsql-hackers
Robert Haas <robertmhaas@gmail.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



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Fwd: Re: A new look at old NFS readdir() problems?
Next
From: Jim Nasby
Date:
Subject: Re: Add the ability to limit the amount of memory that can be allocated to backends.