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 1jtxrN-0008Ak-9M for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Jul 2020 18:34:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jtxrK-0003F1-UD for pgsql-hackers@arkaria.postgresql.org; Fri, 10 Jul 2020 18:34:54 +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 1jtxrK-0003Eu-Ik for pgsql-hackers@lists.postgresql.org; Fri, 10 Jul 2020 18:34:54 +0000 Received: from mail-pg1-x541.google.com ([2607:f8b0:4864:20::541]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jtxrG-0005UU-LC for pgsql-hackers@postgresql.org; Fri, 10 Jul 2020 18:34:53 +0000 Received: by mail-pg1-x541.google.com with SMTP id g67so2885092pgc.8 for ; Fri, 10 Jul 2020 11:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=sGk8EtiaIkWHtQelG31Z95c+PLrQRTJ0XxW+WOc7dOY=; b=JSVBo0WXndO7syaipaFnH9d9Qd6aT1dfRXRcBNb1/SPOwIRu2vxpooVF8VWN+VJBtR BAFkDoZJl5VW0yQxCoke/veDSymANcUyqJ1qMIj6KlpgQwTx6z/vGuU6Yvdd4gShOZYE HmE3aWUpWWwIpJpRzasnRxgMnWN68Oo2f27UH2qpzGdiPNc3PBdUjdZUlbs+BfAfsnls A0yAY3yI7TnZwffQdfCgaSrBm2EOfYvGXocbtGeMDAvs+bf8NooGMsGEwzalXt0BkJxk 4G3lVgpFvd/U+/Twm2wBg7ftrbCOJp5AL2njdJZIdIwtHrMfAp0WJhccK4IyZkIuuFGX vBsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=sGk8EtiaIkWHtQelG31Z95c+PLrQRTJ0XxW+WOc7dOY=; b=kZDFlvtafUKgCsajzrOgunoHxhWWhj/Dv18HjMZBaUCNDIMTCLIChTtU+QEX+SR3Cl bvdPWlxkXOXsf6KJDj8jyiZ82VMBdoLUOV04n+WWKOMzRFnor0kc/94tR88isXoDv1T7 aYXhQyg9CRaua+LhM2dV2N8FF1eNJgoiL8CwA7ae1FgdFwivPUV6FhfanCjOzCf0a7gs RuxLvEArxsP40cuuB0gzdSg2WzTvJf51vAO6X/bUPG00o18lFSrsSJf4p0C4g83A6WeL kewzUCjS4RAUehVsLhPOYoWPO1TP9WOyMrfoFc7Km25T9O4+nnzkhYHEL8u1CKa86cSs skQw== X-Gm-Message-State: AOAM530Ydne/82Fm7Zgur3P44kajgLg8OHbSybf/1HBz3PbTgdZ69WUo EWu22jTxQ4hVEjOP20AtmODPhg== X-Google-Smtp-Source: ABdhPJz3hSxfgo90ElcqZdKDabmaO00WunwOU7oiXj76ln/tJCQiQNms2t360q8IVGVr4+vkYLIU2A== X-Received: by 2002:a63:3d42:: with SMTP id k63mr59221120pga.330.1594406087650; Fri, 10 Jul 2020 11:34:47 -0700 (PDT) Received: from jdavis.lan (c-73-231-146-4.hsd1.ca.comcast.net. [73.231.146.4]) by smtp.gmail.com with ESMTPSA id c187sm6593074pfc.146.2020.07.10.11.34.45 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 10 Jul 2020 11:34:46 -0700 (PDT) Message-ID: <29847045df67838cd72dc2dfe830a11642fb7153.camel@j-davis.com> Subject: Re: Default setting for enable_hashagg_disk From: Jeff Davis To: Tom Lane , Peter Geoghegan Cc: Stephen Frost , Alvaro Herrera , Andres Freund , Bruce Momjian , Robert Haas , David Rowley , Justin Pryzby , Melanie Plageman , Tomas Vondra , "pgsql-hackers@postgresql.org" Date: Fri, 10 Jul 2020 11:34:44 -0700 In-Reply-To: <2107841.1594403217@sss.pgh.pa.us> References: <85F9F4F0-918A-457F-BC9E-F2AC2EFC1F86@anarazel.de> <20200625225853.GA11137@alvherre.pgsql> <20200708140037.GI3125@tamriel.snowman.net> <99b047386525b87df1e611335c2e57a6cdef346b.camel@j-davis.com> <20200709140330.GO3125@tamriel.snowman.net> <20200709225840.GE12375@tamriel.snowman.net> <20200710000842.GF12375@tamriel.snowman.net> <20200710141714.GI12375@tamriel.snowman.net> <2107841.1594403217@sss.pgh.pa.us> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, 2020-07-10 at 13:46 -0400, Tom Lane wrote: > I looked over Peter's patch in [1], and it seems generally pretty > sane to me, though I concur with the idea that it'd be better to > define the GUC as a multiplier for work_mem. (For one thing, we > could > then easily limit it to be at least 1.0, ensuring sanity; also, if > work_mem does eventually become more dynamic than it is now, we might > still be able to salvage this knob as something useful. Or if not, > we just rip it out.) So my vote is for moving in that direction. In that case, I will hold off on my "escape-hatch" GUC. Regards, Jeff Davis