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 по дате отправления: