| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
| Cc: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, Imai Yoshikazu <yoshikazu_i443(at)live(dot)jp>, "jesper(dot)pedersen(at)redhat(dot)com" <jesper(dot)pedersen(at)redhat(dot)com>, "Imai, Yoshikazu" <imai(dot)yoshikazu(at)jp(dot)fujitsu(dot)com>, Amit Langote <amitlangote09(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: speeding up planning with partitions |
| Date: | 2019-03-29 18:32:57 |
| Message-ID: | 8305.1553884377@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christoph Berg | 2019-03-29 18:50:31 | Re: PostgreSQL pollutes the file system |
| Previous Message | Alvaro Herrera | 2019-03-29 18:16:29 | Re: monitoring CREATE INDEX [CONCURRENTLY] |