Re: Should we add GUCs to allow partition pruning to be disabled?
От | Robert Haas |
---|---|
Тема | Re: Should we add GUCs to allow partition pruning to be disabled? |
Дата | |
Msg-id | CA+TgmobsTkQs6Xt3=TjVThRWwm4=9Or7LF0owoqS7LbC+uyS2Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Should we add GUCs to allow partition pruning to be disabled? (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>) |
Ответы |
Re: Should we add GUCs to allow partition pruning to be disabled?
|
Список | pgsql-hackers |
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: