Re: speeding up planning with partitions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: speeding up planning with partitions
Date
Msg-id 8305.1553884377@sss.pgh.pa.us
Whole thread Raw
In response to Re: speeding up planning with partitions  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
List pgsql-hackers
Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> On 2019/03/29 7:38, Tom Lane wrote:
>> 2. I seriously dislike what's been done in joinrels.c, too.  That
>> really seems like a kluge (and I haven't had time to study it
>> closely).

> Those hunks account for the fact that pruned partitions, for which we no
> longer create RangeTblEntry and RelOptInfo, may appear on the nullable
> side of an outer join.  We'll need a RelOptInfo holding a dummy path, so
> that outer join paths can be created with one side of join being dummy
> result path, which are built in the patch by  build_dummy_partition_rel().

Just for the record, that code is completely broken: it falls over
badly under GEQO.   (Try running the regression tests with
"alter system set geqo_threshold to 2".)  However, the partitionwise
join code was completely broken for GEQO before this patch, too, so
I'm just going to log that as an open issue for the moment.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: monitoring CREATE INDEX [CONCURRENTLY]
Next
From: Christoph Berg
Date:
Subject: Re: PostgreSQL pollutes the file system