Re: d25ea01275 and partitionwise join

From: Amit Langote <amitlangote09(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Richard Guo <riguo(at)pivotal(dot)io>, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: d25ea01275 and partitionwise join
Date: 2020-03-01 14:21:29
Message-ID: CA+HiwqHcjFCzzRfht2qs_Dwhia0wBsv1MS8Kwb62dWt1vR+4iw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Feb 29, 2020 at 8:18 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> > On Wed, Nov 6, 2019 at 2:00 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> Just to leave a breadcrumb in this thread --- the planner failure
> >> induced by d25ea01275 has been fixed in 529ebb20a. The difficulty
> >> with multiway full joins that Amit started this thread with remains
> >> open, but I imagine the posted patches will need rebasing over
> >> 529ebb20a.
>
> > Here are the rebased patches.
>
> The cfbot shows these patches as failing regression tests. I think
> it is just cosmetic fallout from 6ef77cf46 having changed EXPLAIN's
> choices of table alias names; but please look closer to confirm,
> and post updated patches.

Thanks for notifying.

Checked and indeed fallout from 6ef77cf46 seems to be the reason a
test is failing.

Updated patches attached.

Thanks,
Amit

Attachment Content-Type Size
v5-0002-Move-some-code-from-joinrel.c-to-relnode.c.patch application/octet-stream 12.0 KB
v5-0001-Some-cosmetic-improvements-to-partitionwise-join-.patch application/octet-stream 12.9 KB
v5-0003-Fix-partitionwise-join-to-handle-FULL-JOINs-corre.patch application/octet-stream 13.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Fearing 2020-03-01 14:49:32 Re: proposal \gcsv
Previous Message Julien Rouhaud 2020-03-01 14:05:10 Re: Planning counters in pg_stat_statements (using pgss_store)