Re: Runtime pruning problem

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: Runtime pruning problem
Дата
Msg-id 465f3e76-2d9e-90af-5a31-1101293e47b4@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Runtime pruning problem  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On 2019/04/19 17:00, Amit Langote wrote:
> On 2019/04/19 2:25, Tom Lane wrote:
>> Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
>>> Another idea is to teach explain.c about this special case of run-time
>>> pruning having pruned all child subplans even though appendplans contains
>>> one element to cater for targetlist accesses.  That is, Append will be
>>> displayed with "Subplans Removed: All" and no child subplans listed below
>>> it, even though appendplans[] has one.  David already said he didn't do in
>>> the first place to avoid PartitionPruneInfo details creeping into other
>>> modules, but maybe there's no other way?
>>
>> I tried simply removing the hack in nodeAppend.c (per quick-hack patch
>> below), and it gets through the core regression tests without a crash,
>> and with output diffs that seem fine to me.  However, that just shows that
>> we lack enough test coverage; we evidently have no regression cases where
>> an upper node needs to print Vars that are coming from a fully-pruned
>> Append.  Given the test case mentioned in this thread, I get
>>
>> regression=# explain verbose select * from t1 where dt = current_date + 400;
>>                  QUERY PLAN                  
>> ---------------------------------------------
>>  Append  (cost=0.00..198.42 rows=44 width=8)
>>    Subplans Removed: 4
>> (2 rows)
>>
>> which seems fine, but
>>
>> regression=# explain verbose select * from t1 where dt = current_date + 400 order by id;
>> psql: server closed the connection unexpectedly
>>
>> It's dying trying to resolve Vars in the Sort node, of course.
> 
> Another approach, as I mentioned above, is to extend the hack that begins
> in nodeAppend.c (and nodeMergeAppend.c) into explain.c, as in the
> attached.  Then:
> 
> explain verbose select * from t1 where dt = current_date + 400 order by id;
>                     QUERY PLAN
> ───────────────────────────────────────────────────
>  Sort  (cost=199.62..199.73 rows=44 width=8)
>    Output: t1_1.id, t1_1.dt
>    Sort Key: t1_1.id
>    ->  Append  (cost=0.00..198.42 rows=44 width=8)
>          Subplans Removed: 4
> (5 rows)
> 
> It's pretty confusing to see t1_1 which has been pruned away, but you
> didn't seem very interested in the idea of teaching explain.c to use the
> original target list of plans like Append, MergeAppend, etc. that have
> child subplans.
> 
> Just a note: runtime pruning for MergeAppend is new in PG 12.

The patch I attached with the previous email didn't update the expected
output file.  Correct one attached.

Thanks,
Amit

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Langote
Дата:
Сообщение: Re: Runtime pruning problem
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: TM format can mix encodings in to_char()