Re: Should we add GUCs to allow partition pruning to be disabled?
От | Amit Langote |
---|---|
Тема | Re: Should we add GUCs to allow partition pruning to be disabled? |
Дата | |
Msg-id | CA+HiwqG5Bf2NeDVsz3Lf=uLZw-7GZjz5WFmnnPfDRr-_mc9oGw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Should we add GUCs to allow partition pruning to be disabled? (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Sat, May 19, 2018 at 5:02 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, May 18, 2018 at 4:22 AM, Amit Langote > <Langote_Amit_f8@lab.ntt.co.jp> wrote: >> Yeah, I think it'd help to have Append be annotated as suggested by Robert >> above. I guess if "at executor startup" is shown, then the subnodes >> listed under Append will consist of only those that survived >> executor-startup pruning and thus will help understand why there are fewer >> than shown with EXPLAIN (without ANALYZE). Also, if "at runtime" is >> shown, a user may want look at nloops property of the individual subnodes >> to guess at how much pruning has occurred; although only the latter (that >> is, inspecting nloops) suffices to know that runtime pruning has occurred >> as also currently written in the documentation about pruning [1], the >> first piece of information (the "at runtime" annotation) seems nice to have. > > Having EXPLAIN and EXPLAIN ANALYZE show different things doesn't sound > like a good idea. Hmm yeah. I think I was misunderstanding how executor-startup pruning works when I wrote: ...and thus will help understand why there are fewer than shown with EXPLAIN (without ANALYZE). Actually, because ExecInitAppend would run for both EXPLAIN and EXPLAIN ANALYZE, executor-startup pruning should occur in both cases and will result in the same plan shape to be shown. Sorry about the confusion. Thanks, Amit
В списке pgsql-hackers по дате отправления: