From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | pgsql-performance(at)lists(dot)postgresql(dot)org,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Felix Geisendörfer <felix(at)felixge(dot)de>,"pgsql-performa(dot)" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Extremely slow HashAggregate in simple UNION query |
Date: | 2019-08-24 19:54:03 |
Message-ID: | 28D9A4C8-913F-42B2-8B0B-8A8F381209EE@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi,
On August 24, 2019 12:41:03 PM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Jeff Janes <jeff(dot)janes(at)gmail(dot)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 display it 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 executor startup is a very large fraction of the total time, without massive misestimations. Optimizing that could be easier with that information available.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2019-08-25 14:50:55 | Re: Erratically behaving query needs optimization |
Previous Message | Tom Lane | 2019-08-24 19:41:03 | Re: Extremely slow HashAggregate in simple UNION query |