Re: A problem about partitionwise join

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Richard Guo <riguo(at)pivotal(dot)io>, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Amit Langote <amitlangote09(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A problem about partitionwise join
Date: 2020-04-09 04:14:24
Message-ID: CAMbWs4-zhLVU-uH42_N_v-LQF+VTGruVadQr6A_amhjmugB9-g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 9, 2020 at 1:07 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> > On Sun, Apr 5, 2020 at 4:38 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> There is already something in equivclass.c that would almost do what
> >> we want here: exprs_known_equal() would tell us whether the partkeys
> >> can be found in the same eclass, without having to generate data
> >> structures along the way. The current implementation is not watertight
> >> because it doesn't check opclass semantics, but that consideration
> >> can be bolted on readily enough. So that leads me to something like
> >> the attached.
>
> > I have some concern about we only check non-nullable partexprs. Is it
> > possible that two nullable partexprs come from the same EC? I tried to
> > give an example but failed.
>
> Currently the EC infrastructure doesn't really cope with outer join
> equijoins. They are not treated as producing true equivalences,
> so I think that the case you're worried about can't occur (which is why
> I didn't code for it). I have hopes of being able to incorporate outer
> joins into the EC logic in a less squishy way in the future, by making
> the representation of Vars distinguish explicitly between
> value-before-outer-join and value-after-outer-join, after which we could
> make bulletproof assertions about what is equal to what, even with outer
> joins in the mix. If that works out it might produce a cleaner answer
> in this area too.
>

This is very appealing. Do we have ongoing discussions/threads about
this idea?

> (I did experiment with
> removing all the rest of have_partkey_equi_join() and having it
> *only* ask exprs_known_equal() about equivalences, which is more or
> less what I'm envisioning here. That caused some of the existing
> regression tests to fail, so there's something that the idea isn't
> covering. I didn't dig any further at the time, and in particular
> failed to check whether the problems were specifically about outer
> joins, which'd be unsurprising given the above.)
>

I think it would not work for outer joins if we only check
exprs_known_equal() for equivalences. If the equi-join conditions
involving pairs of matching partition keys are outer join quals
mentioning nonnullable side rels, they would not exist in any EC
according to the current EC infrastructure. So we still have to look
through restrictlist.

Thanks
Richard

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2020-04-09 04:59:22 Re: [HACKERS] advanced partition matching algorithm for partition-wise join
Previous Message Fujii Masao 2020-04-09 04:00:03 Re: Planning counters in pg_stat_statements (using pgss_store)