Re: Extremely slow HashAggregate in simple UNION query

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.

In response to

Browse pgsql-performance by date

  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