Re: Extremely slow HashAggregate in simple UNION query

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Extremely slow HashAggregate in simple UNION query
Дата
Msg-id 28D9A4C8-913F-42B2-8B0B-8A8F381209EE@anarazel.de
обсуждение исходный текст
Ответ на Re: Extremely slow HashAggregate in simple UNION query  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-performance
Hi,

On August 24, 2019 12:41:03 PM PDT, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Jeff Janes <jeff.janes@gmail.com> writes:
>> Most of the time is not after the clock stops, but before the
>stepwise
>> ANALYZE clock starts.  If you just do an EXPLAIN rather than EXPLAIN
>> ANALYZE, that is also slow.  The giant hash table is created during
>the
>> planning step (or somewhere around there
>
>It's in executor startup, I believe.

I'm sure personally interested in doing so, but it'd not be hard to measure the executor startup time separately. And
displayit either on a per node basis, or as a total number. 

Quite unconvinced this thread is a convincing reason to do so (or really do anything). But for some other workloads
executorstartup is a very large fraction of the total time, without massive misestimations. Optimizing that could be
easierwith that information available. 

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Extremely slow HashAggregate in simple UNION query
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: Erratically behaving query needs optimization