Sorry about the late reply.
On Mon, Oct 14, 2019 at 11:54 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Justin Pryzby <pryzby@telsasoft.com> writes:
> > On Sun, Oct 13, 2019 at 01:30:29PM -0500, Justin Pryzby wrote:
> >> BTW it probably should've been documented as an "Open Item" for v12.
>
> > https://commitfest.postgresql.org/25/2278/
> > I realized possibly people were thinking of that as a "feature" and not a
> > bugfix for backpatch (?)
> > But, my issue is a query which worked under v11 PWJ but fails under v12
> > (apparently broken by d25ea01275).
>
> Yeah, this should have been dealt with as an open item, but it
> slipped through the cracks. We'll make sure to get it fixed,
> one way or another, for 12.1.
>
> In view of the proposed patches being dependent on some other
> 13-only changes, I wonder if we should fix v12 by reverting
> d25ea0127. The potential planner performance loss for large
> partition sets could be nasty, but failing to plan at all is worse.
Actually, the patch I proposed to fix equivalence code can be applied
on its own. The example I gave on that thread needs us to fix
partitionwise code to even work, which is perhaps a 13-only change,
but we have an example here that is broken due to d25ea01275.
Perhaps, considering applying my patch seems better than alternatives
which are either reverting d25ea01275 or avoiding doing partitionwise
join for such queries.
Since we've got 3373c71553 ("Speed up finding EquivalenceClasses for a
given set of rels") in HEAD, need two versions of the patch; please
see attached.
Thanks,
Amit