Re: speeding up planning with partitions

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: speeding up planning with partitions
Дата
Msg-id 8305.1553884377@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: speeding up planning with partitions  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список 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 по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: monitoring CREATE INDEX [CONCURRENTLY]
Следующее
От: Christoph Berg
Дата:
Сообщение: Re: PostgreSQL pollutes the file system