Horton

Re: [HACKERS] advanced partition matching algorithm for partition-wise join

Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>

View thread
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: amul sul <sulamul@gmail.com>, Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>, Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>, Dmitry Dolgov <9erthalion6@gmail.com>, Thomas Munro <thomas.munro@enterprisedb.com>, Antonin Houska <ah@cybertec.at>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2019-05-14T14:11:39Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Suppress unused-variable warning.

  2. Allow partitionwise joins in more cases.

  3. Avoid crash in partitionwise join planning under GEQO.

  4. Disable support for partitionwise joins in problematic cases.

  5. Add plan_cache_mode setting

  6. Add test for partitionwise join involving default partition.

  7. Revise API for partition_rbound_cmp/partition_rbound_datum_cmp.

On Tue, May 14, 2019 at 10:00 AM Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
wrote:

> On 2019/05/14 13:23, Amit Langote wrote:
> > Tom
> > strongly objected to that idea saying that such join paths are kind of
> > silly [1], even outside the context of partitionwise join.  He suggested
> > that we abandon partitionwise join in such cases, because having to build
> > a dummy base relation for pruned partitions only to generate
> silly-looking
> > paths would be an ugly kludge.
>
> I forgot to mention that he even committed a patch to disable
> partitionwise joins in such cases, which was also applied to v11 branch.
>
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=d70c147fa217c4bae32ac1afb86ab42d98b36fdf
>
> Note that there were also other reasons for committing, beside what I
> described in my previous email.
>
>
I haven't seen the actual commit, but we could use these patches to enable
partition-wise join when partitions are pruned. For that the partition
descriptor of the pruned partition table should be arranged as if those
partitions are missing in the table itself. However, we will still need
code to handle the cases when the partitions are missing on the nullable
side. Tom mentioned the idea of using just projection to produce join
tuples with rows on the outer side appended with null columns from the
nullable side. If we can implement that, we can remove the restrictions in
this patch.

--
Best Wishes,
Ashutosh Bapat