pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Arne Roland <A.Roland@index.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <riguo@pivotal.io>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Subject: Re: Partial join
Date: Thu, 1 Aug 2019 16:29:21 +0000
Message-ID: <563d1a984c2c41b5b126318aafceab11@index.de> (raw)
In-Reply-To: <5928.1564668894@sss.pgh.pa.us>
References: <9dc03e949e9b4327a0d074da9ab44318@index.de>
	<dd01626a46a342f7b1d811cf38fcebe6@index.de>
	<CAN_9JTxQtJr2RHLKAfDCJoZFF+qsUMAF5JF+BVyAVcmcC2kSQA@mail.gmail.com>
	<5928.1564668894@sss.pgh.pa.us>

"Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> Uh ... why?  The pushed-down restrictions should result in pruning
> away any prunable partitions at the scan level, leaving nothing for
> the partitionwise join code to do.

It seems reasonable to me that the join condition can no longer be verified, since  'sc.sl = sg.sl' is now replaced by 'sg.sl = 5' so the join condition can no longer be validated.

It's true that the pruning would prune everything but one partition, in case we'd just have a single column partition key. But we don't. I don't see how pruning partitions should help in this case, since we are left with multiple partitions for both relations.

Regards
Arne

________________________________
From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Thursday, August 1, 2019 4:14:54 PM
To: Richard Guo
Cc: Arne Roland; pgsql-hackers@lists.postgresql.org
Subject: Re: Partial join

Richard Guo <riguo@pivotal.io> writes:
> For the third query,  a rough investigation shows that, the qual 'sl =
> 5' and 'sc.sl = sg.sl' will form an equivalence class and generate two
> implied equalities: 'sc.sl = 5' and 'sg.sl = 5', which can be pushed
> down to the base rels. One consequence of the deduction is when
> constructing restrict lists for the joinrel, we lose the original
> restrict 'sc.sl = sg.sl', and this would fail the check
> have_partkey_equi_join(), which checks if there exists an equi-join
> condition for each pair of partition keys. As a result, this joinrel
> would not be considered as an input to further partitionwise joins.

> We need to fix this.

Uh ... why?  The pushed-down restrictions should result in pruning
away any prunable partitions at the scan level, leaving nothing for
the partitionwise join code to do.

                        regards, tom lane

view thread (9+ messages)  latest in thread

Message-ID: <563d1a984c2c41b5b126318aafceab11@index.de>
Permalink:  ../563d1a984c2c41b5b126318aafceab11@index.de/
Also on:    postgresql.org/message-id/563d1a984c2c41b5b126318aafceab11@index.de

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: A.Roland@index.de, tgl@sss.pgh.pa.us, riguo@pivotal.io, pgsql-hackers@lists.postgresql.org
  Subject: Re: Partial join
  In-Reply-To: <563d1a984c2c41b5b126318aafceab11@index.de>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox