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 1jnvsD-00057J-Gt for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Jun 2020 03:14:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jnvsC-0000va-D9 for pgsql-hackers@arkaria.postgresql.org; Wed, 24 Jun 2020 03:14:52 +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 1jnvsC-0000vR-2p for pgsql-hackers@lists.postgresql.org; Wed, 24 Jun 2020 03:14:52 +0000 Received: from mail-io1-xd29.google.com ([2607:f8b0:4864:20::d29]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jnvs7-0001SU-FF for pgsql-hackers@postgresql.org; Wed, 24 Jun 2020 03:14:51 +0000 Received: by mail-io1-xd29.google.com with SMTP id c16so575286ioi.9 for ; Tue, 23 Jun 2020 20:14:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=3v8IXlKkjVbmQj0nN6JJxCl9zwH4X1ZCSzR1RAi/qC0=; b=Kd5B9InUIrjO4twXiO9T3h4TMA9d44t6RbKf8FtbU5O8dxRK3k3C3TW0+0Pr1yedY8 axXNJxY6QxejFJ3Dqr2qO99eoBReB1oQfq3tkS37Yxr4dQ/JbFSRaeZ+hiy8Bm6ikVga z/980bB5636sVUW0Jb/cFfHQCClhpJSG4y1mQpmXIqbcYDX12bpxSsTagt8+wM4doH99 4bUMMfGIEfbQkML7E/M7mhfsYzfKS9g0NkdlY45kMqwQgmHeZ8Fl//LvrhrQ+VfzU9Uj 6H1fPOhJemIfGkU27CrrjFbELv9Uuv7fxXHw9J1BA3Qyh8wTFUM4dEhmppMTyrmr35jG 9Pdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=3v8IXlKkjVbmQj0nN6JJxCl9zwH4X1ZCSzR1RAi/qC0=; b=JisVf5F3JeIorHYnwK9tOVsgvnaqP7GqWRfEo8/XWolfYoxzgklk8Bw7qJVnmuut3S fVOVNd8vGah8HEZiC6Pnp7zngM8FaCMPy/v7t09jpA/9A4LeubUv9dcX41Ipu8uh9cSB olUW67OgNmeyl93Ww1PN6b2TpIImRi5kzhNOAP7/dcNocC52uM1KRiXtklp6ybrsz+yB 7Y8grPwBAAQ7QFDUHUUi6CdAlXwnDUPh3zXaSm1E6nU/ah0MFAqRudRzp8+vG2ejKKK/ hUXgTlzHYm2GHT+fFxJAPu2L0IBJeFyvGMheQhjUbIAIyUBHUwlOeb0XBxVHy8UXB0M6 gG8A== X-Gm-Message-State: AOAM532qfgf4zCtA43XVIY6TSCq/cnumPoO4gMmvdKdE0Xql4nPSrm56 JETHbFqfwnnL0ODqV6LEX18sBQ== X-Google-Smtp-Source: ABdhPJz7rEc+PxuZHqeyZTiKwvI6t+HVTMVTZqpF5WKHcDmG7XH0X6KO65C/7jRrkye0NE0P7GgDNA== X-Received: by 2002:a02:1745:: with SMTP id 66mr27493913jah.141.1592968485887; Tue, 23 Jun 2020 20:14:45 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id h14sm10466810ilo.10.2020.06.23.20.14.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jun 2020 20:14:44 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 94F33800138; Tue, 23 Jun 2020 22:14:43 -0500 (CDT) Date: Tue, 23 Jun 2020 22:14:43 -0500 From: Justin Pryzby To: David Rowley Cc: Jeff Davis , Robert Haas , Melanie Plageman , Tomas Vondra , pgsql-hackers@postgresql.org Subject: Re: Default setting for enable_hashagg_disk Message-ID: <20200624031443.GV4107@telsasoft.com> References: <6292f5a766198d5745eb8cc17ac736366056671d.camel@j-davis.com> <20200610021544.GA14879@telsasoft.com> <8bff2e4e8020c3caa16b61a46918d21b573eaf78.camel@j-davis.com> <129c8f1739957589584d9525e1d8782eae3f412f.camel@j-davis.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Wed, Jun 24, 2020 at 02:11:57PM +1200, David Rowley wrote: > On Tue, 23 Jun 2020 at 08:24, Jeff Davis wrote: > > Another way of looking at it is that the weird behavior is already > > there in v12, so there are already users relying on this weird behavior > > as a crutch for some other planner mistake. The question is whether we > > want to: Yea - "behavior change" is a scenario for which it's hard to anticipate well all the range of consequences. > How about: > > enable_hashagg = "on" -- enables hashagg allowing it to freely spill > to disk as it pleases. > enable_hashagg = "trynospill" -- Planner will only choose hash_agg if > it thinks it won't spill (pre PG13 planner behaviour) > enable_hashagg = "neverspill" -- executor will *never* spill to disk > and can still OOM (NOT RECOMMENDED, but does give pre PG13 planner and > executor behaviour) > enable_hashagg = "off" -- planner does not consider hash agg, ever. > Same as what PG12 did for this setting. +1 I like that this allows the new behavior as an *option* one *can* use rather than a "behavior change" which is imposed on users and which users then *have* to accomodate in postgres. -- Justin