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?  (Amit Langote <amitlangote09@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: 'tuple concurrently updated' error w/o visible catalog updates
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Built-in connection pooling