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 1jub88-0006fT-Jr for pgsql-hackers@arkaria.postgresql.org; Sun, 12 Jul 2020 12:30:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jub87-0000cA-8S for pgsql-hackers@arkaria.postgresql.org; Sun, 12 Jul 2020 12:30:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jub86-0000bh-Te for pgsql-hackers@lists.postgresql.org; Sun, 12 Jul 2020 12:30:51 +0000 Received: from mail-ed1-x542.google.com ([2a00:1450:4864:20::542]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jub84-0007MW-7n for pgsql-hackers@postgresql.org; Sun, 12 Jul 2020 12:30:49 +0000 Received: by mail-ed1-x542.google.com with SMTP id bm28so6353056edb.2 for ; Sun, 12 Jul 2020 05:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=+6s79sUD0DyQWJ6reSoc8bqBrWr96HrVVKmimFUjTT4=; b=Bb4zxMahEd0NVOH8cthxI9g2yd4ZoMMjQOItDjcTvwJxdIYu9z4dj9/LdixqdAGgcY DGLymA282T1eIvw1+ZQDJwFSVR/VA/y8Xgp+obMHbQX09+Hjwloj1ugX2BrHwWPnpSbo VQIEVmsT4NXVgdtn1j+v6qZRAN51xSkKod3ZNfserJsNOoFILVSveh8pJ8mTAF3QoufA WoUesgcYip+y6paZpDesPLhLRdmsSBc+ZtgUNMnnJEqVh/BI0G2CP4qvA+tK2//vchdG 6vFJgzVZqJ6XVUfVkbur996esjJjXg6HEyQTtQAjPbE1iI8k3qiJolyajrSwfb5472ul FQ5g== 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; bh=+6s79sUD0DyQWJ6reSoc8bqBrWr96HrVVKmimFUjTT4=; b=fEh9do6+tXZ3E5xc4b1C7/219cXWWnz8kSLurOx6I82uF9BEiWn82YmDXcX1YnpmEg 1H8xaC9nCl5U/Kb5jjF+3xBmsdKYK8UAxZXLmQ3QKNf0BUq7vYSQMmaH1kRbjeoDu8cM UaCkzAacY0/FOfnqmY9sVYGR9CbwB9Qe9LUlKIR+2YWOK2D8zluaMflu+cBluwbcAuRH q1Absd1mWRm/gMRgveq/ju2QuBMMeRKjUEtqwm9yD6uOL3Du5Kn34+yk4bCTKYtxF4qz VGwmgd/riOMWr1Os3KWm6LZS8ejqESNqI0xmoYx1TpOz50AFvw05hd6WBt4yxACuD001 gE5A== X-Gm-Message-State: AOAM530xQlfn2Q312/ZyHswyY0hnuKP3Zr4gpANBX78O0IIJJe52XAzo KeMQS90ohIZw8sgMAS7LGFXCHQ== X-Google-Smtp-Source: ABdhPJyTKGBJWrpnhIFhqKRhcZ9tt76vSxXBKjgOwFM+YOW6By5DTbJc625Pplr+5fJMwQNTdylZPg== X-Received: by 2002:aa7:cf94:: with SMTP id z20mr88729738edx.82.1594557046821; Sun, 12 Jul 2020 05:30:46 -0700 (PDT) Received: from localhost (ip-86-49-253-141.net.upcbroadband.cz. [86.49.253.141]) by smtp.gmail.com with ESMTPSA id x9sm7584712ejw.28.2020.07.12.05.30.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Jul 2020 05:30:45 -0700 (PDT) Date: Sun, 12 Jul 2020 14:30:43 +0200 From: Tomas Vondra To: Tom Lane Cc: "David G. Johnston" , Stephen Frost , Peter Geoghegan , Jeff Davis , Alvaro Herrera , Andres Freund , Bruce Momjian , Robert Haas , David Rowley , Justin Pryzby , Melanie Plageman , "pgsql-hackers@postgresql.org" Subject: Re: Default setting for enable_hashagg_disk Message-ID: <20200712123043.hnjsluya5mbwhnq4@development> References: <20200710000842.GF12375@tamriel.snowman.net> <20200710141714.GI12375@tamriel.snowman.net> <20200710215012.GN12375@tamriel.snowman.net> <2165606.1594418399@sss.pgh.pa.us> <20200711142213.GP12375@tamriel.snowman.net> <20200712003037.wzrcltujwzwiwlfr@development> <2463591.1594514874@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <2463591.1594514874@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sat, Jul 11, 2020 at 08:47:54PM -0400, Tom Lane wrote: >Tomas Vondra writes: >> I don't know, but one of the main arguments against simply suggesting >> people to bump up work_mem (if they're hit by the hashagg spill in v13) >> was that it'd increase overall memory usage for them. It seems strange >> to then propose a new GUC set to a default that would result in higher >> memory usage *for everyone*. > >It seems like a lot of the disagreement here is focused on Peter's >proposal to make hash_mem_multiplier default to 2.0. But it doesn't >seem to me that that's a critical element of the proposal. Why not just >make it default to 1.0, thus keeping the default behavior identical >to what it is now? > >If we find that's a poor default, we can always change it later; >but it seems to me that the evidence for a higher default is >a bit thin at this point. > You're right, I was specifically pushing against that aspect of the proposal. Sorry for not making that clearer, I assumed it's clear from the context of this (sub)thread. I agree making it 1.0 (or equal to work_mem, if it's not a multiplier) by default, but allowing it to be increased if needed would address most of the spilling issues. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services