Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <pgsql-performance-owner+archive@lists.postgresql.org>)
	id 1i1buP-000373-HR
	for pgsql-performance@arkaria.postgresql.org; Sat, 24 Aug 2019 19:41:09 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <pgsql-performance-owner+archive@lists.postgresql.org>)
	id 1i1buO-0005w5-BI
	for pgsql-performance@arkaria.postgresql.org; Sat, 24 Aug 2019 19:41:08 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1i1buN-0005ub-VZ
	for pgsql-performance@lists.postgresql.org; Sat, 24 Aug 2019 19:41:08 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1i1buL-0005hU-MY
	for pgsql-performance@postgresql.org; Sat, 24 Aug 2019 19:41:06 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x7OJf3kx006840;
	Sat, 24 Aug 2019 15:41:03 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Janes <jeff.janes@gmail.com>
cc: Pavel Stehule <pavel.stehule@gmail.com>,
        =?UTF-8?Q?Felix_Geisend=C3=B6rfer?= <felix@felixge.de>,
        "pgsql-performa." <pgsql-performance@postgresql.org>
Subject: Re: Extremely slow HashAggregate in simple UNION query
In-reply-to: 
 <CAMkU=1yiC23_F5OvQfh2qN2OMTx-95njbz2uskPB01dt2d_BNA@mail.gmail.com>
References: <9ADCDD19-555B-4DB0-B00C-1852AC361557@felixge.de>
 <CAMkU=1x+aT9kWCWKoskOdQPAdXZwLsv-cpKJ6B=rytCibfrpyA@mail.gmail.com>
 <CAFj8pRBsp+8FNEqVz9b76qMGn8P3-O5kFNiLkvu55Q+d+ntx5A@mail.gmail.com>
 <CAMkU=1yiC23_F5OvQfh2qN2OMTx-95njbz2uskPB01dt2d_BNA@mail.gmail.com>
Comments: In-reply-to Jeff Janes <jeff.janes@gmail.com>
	message dated "Sat, 24 Aug 2019 15:16:10 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6838.1566675663.1@sss.pgh.pa.us>
Date: Sat, 24 Aug 2019 15:41:03 -0400
Message-ID: <6839.1566675663@sss.pgh.pa.us>
List-Id: <pgsql-performance.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-performance@lists.postgresql.org>
List-Owner: <mailto:pgsql-performance-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-performance>
Precedence: bulk

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.

			regards, tom lane