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 1jmlau-0001u0-IL for pgsql-hackers@arkaria.postgresql.org; Sat, 20 Jun 2020 22:04:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jmlat-0005A8-Fa for pgsql-hackers@arkaria.postgresql.org; Sat, 20 Jun 2020 22:04:11 +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 1jmlat-00059x-4P for pgsql-hackers@lists.postgresql.org; Sat, 20 Jun 2020 22:04:11 +0000 Received: from mail-il1-x133.google.com ([2607:f8b0:4864:20::133]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jmlap-0004lP-O9 for pgsql-hackers@postgresql.org; Sat, 20 Jun 2020 22:04:10 +0000 Received: by mail-il1-x133.google.com with SMTP id 9so12645888ilg.12 for ; Sat, 20 Jun 2020 15:04:06 -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=Fqik+Sj6MMsgo6B8XlY4dK7Xn52CeujMP9s/u+J6EtM=; b=1rMYh+uOIoVuNMtqPDwX3ggSLVMW1dzh5YdfWLqCJGzUgv08SBTbHPI423jAly6FRy 3KmzQU6hK4tzLje0geaFm7WS1ziyTQO9hhEwjybspAY3RrGdPrM+icxNf3g1pTwQYO2m eeWLq0z9TTB9rHu1SKOIzB6FjYhXKhghKSYHfzraxr2UtrZooWrUgCnLWmyUl7l0JAL+ dQOC6g57UI5DFM8MiOAW9CBH5PWF2HkhD92NG32a0tvD/hCHPm3n1gYcHdFOWu5kIwtw rXr8eagpBeVoJnGRSvEUXFvXIPgRwlXCFCDaHLAu2w5jPJOlYvhjqh+wBY7tCm1eTyEi Dkqg== 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=Fqik+Sj6MMsgo6B8XlY4dK7Xn52CeujMP9s/u+J6EtM=; b=LP2Pj8Htyz2koG+pDzmpK+S26ijY8zmtyAfXCZqr/UZQoSaS9+hO5Yiy5daURVCVge 3kEhd74kpmjGi2Y8pHJv2s4hwwO3riP+zoHtvQ9oxBpJz0nOCn4z8l+TMTg0hG2PRojl 4ef58RAFl0Qc/aUltGQcO4Khfpok3rhSJGpqKNp+XP6JrtkGtKr7af61ebCiNA2v+NsR cMD4b3f2KOP/8wdh5SG3PnuQAgcrbYxaikLy9yQYQa/I03PObud9EzrRbt0rDOA4TBOM ah1LFueX3FveBFdzpXQVUBNdN+OKGr9r3uRbqfvqs2IU2taFE/2SLDA+911ZVyc5TtHg ItXA== X-Gm-Message-State: AOAM5319cuFvBm3ZBqnyYfSWVztoYHKsV+mVMogpNDIcWCUtDQgRtnJO s5jCkMpz+RNLN0OnPcsfD2ppZw== X-Google-Smtp-Source: ABdhPJzoLMslgda+bcBAAcfz3e85lhXab2EsjxIXtBnLn4GKydSCZ2n0QhYLhR1M688xS6jqePRsHQ== X-Received: by 2002:a92:bb0b:: with SMTP id w11mr1844965ili.238.1592690644482; Sat, 20 Jun 2020 15:04:04 -0700 (PDT) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id c23sm5722082ioc.28.2020.06.20.15.04.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jun 2020 15:04:03 -0700 (PDT) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 8215C800A36; Sat, 20 Jun 2020 17:04:02 -0500 (CDT) Date: Sat, 20 Jun 2020 17:04:02 -0500 From: Justin Pryzby To: Jeff Davis Cc: Melanie Plageman , Robert Haas , Tomas Vondra , pgsql-hackers@postgresql.org Subject: Re: Default setting for enable_hashagg_disk Message-ID: <20200620220402.GZ17995@telsasoft.com> References: <9d9d1e1252a52ea1bad84ea40dbebfd54e672a0f.camel@j-davis.com> <20200407223900.GT2228@telsasoft.com> <20200409114855.h4hh7e2wt77p56sv@development> <6292f5a766198d5745eb8cc17ac736366056671d.camel@j-davis.com> <20200610021544.GA14879@telsasoft.com> <8bff2e4e8020c3caa16b61a46918d21b573eaf78.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 Thu, Jun 11, 2020 at 01:22:57PM -0700, Jeff Davis wrote: > > think the names you suggested quite fit, but the idea to use a more > > interesting GUC value might help express the behavior. Perhaps making > > enable_hashagg a ternary "enable_hashagg=on|off|avoid_disk"? The word > > "reject" is too definite for the planner, which is working with > > imperfect information. > > I renamed enable_hashagg_disk to hashagg_avoid_disk_plan, which I think > satisfies the concerns raised here. Also in 92c58fd9. I think this should be re-arranged to be in alphabetical order https://www.postgresql.org/docs/devel/runtime-config-query.html -- Justin