Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jo8t7-0003ID-1x for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Jun 2020 17:08:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jo8t5-0003Gq-Ve for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Jun 2020 17:08:39 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jo8t5-0003Fr-P3 for pgsql-hackers@lists.postgresql.org; Wed, 24 Jun 2020 17:08:39 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jo8t3-0000Nz-2l for pgsql-hackers@postgresql.org; Wed, 24 Jun 2020 17:08:39 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1jo8t0-0005tD-5t; Wed, 24 Jun 2020 13:08:34 -0400 Date: Wed, 24 Jun 2020 13:08:34 -0400 From: Bruce Momjian To: Justin Pryzby Cc: David Rowley , Jeff Davis , Robert Haas , Melanie Plageman , Tomas Vondra , pgsql-hackers@postgresql.org Subject: Re: Default setting for enable_hashagg_disk Message-ID: <20200624170834.GA17842@momjian.us> References: <20200610021544.GA14879@telsasoft.com> <8bff2e4e8020c3caa16b61a46918d21b573eaf78.camel@j-davis.com> <129c8f1739957589584d9525e1d8782eae3f412f.camel@j-davis.com> <20200624090628.GA19640@momjian.us> <20200624123843.GX4107@telsasoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200624123843.GX4107@telsasoft.com> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Jun 24, 2020 at 07:38:43AM -0500, Justin Pryzby wrote: > On Wed, Jun 24, 2020 at 05:06:28AM -0400, Bruce Momjian wrote: > > It would seem merge join has almost the same complexities as the new > > hash join code, since it can spill to disk doing sorts for merge joins, > > and adjusting work_mem is the only way to control that spill to disk. I > > don't remember anyone complaining about spills to disk during merge > > join, so I am unclear why we would need a such control for hash join. > > It loooks like merge join was new in 8.3. I don't think that's a good analogy, > since the old behavior was still available with enable_mergejoin=off. Uh, we don't gurantee backward compatibility in the optimizer. You can turn off hashagg if you want. That doesn't get you to PG 13 behavior, but we don't gurantee that. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee