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 1jrRhJ-0001Eg-I9 for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jul 2020 19:50:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jrRhI-0007DW-HP for pgsql-hackers@arkaria.postgresql.org; Fri, 03 Jul 2020 19:50:08 +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 1jrRhI-0007DO-6Y for pgsql-hackers@lists.postgresql.org; Fri, 03 Jul 2020 19:50:08 +0000 Received: from mail-qk1-x741.google.com ([2607:f8b0:4864:20::741]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jrRhG-0005xs-4c for pgsql-hackers@postgresql.org; Fri, 03 Jul 2020 19:50:07 +0000 Received: by mail-qk1-x741.google.com with SMTP id q198so29735511qka.2 for ; Fri, 03 Jul 2020 12:50:05 -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:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=maUcPWOnSlOV+eDJaz/nePVGHk+NSd5vCOZwmUpgPxI=; b=oLbK55FF9ubtpy7LNKgwx30+WZBbhyFwGZtLLDRMOiaaVOjS7G5iw8+8EVZKBtVRt0 pNL3rdu2WRuaoAktMOV4hO5jFE6MmjKfwrN/hX28QoX1XjBd7Hm+BuU+ooL+cIh4+cT6 RUoZu/WGr+oangc8kEiopKsY3vRJXI18traahKAhTkxToPXDAm5POUeWTievSXtsCPC9 MPJdBqSGdITPItY5Zd3eAeHyVgC7W8zpvr+VpmZROGJzoKtabG1XwnxvlqTk6OX233wr d0lFzkUVUPc6qRoBfoeH4po2HZH+iUqRQc5ucTFx65IH2aE8PuwX/8968pcWOm5PpJEX 8O3g== 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:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=maUcPWOnSlOV+eDJaz/nePVGHk+NSd5vCOZwmUpgPxI=; b=HBzOxSwjvTqC+QeM3LeS3TXXMzmy/QyEI0gWhk0rD68Vq1F7p6e6JZTnGqeynu7ez0 CW9aUJX7Iw+uqvMytU61NoTMYrWo2DXCY75G5/wpXsOEuy77CYW6Z+1CTOWCh1sEZre2 RmDft/cr33vUvHvm8UmZ6iHF6kEPTCbBOW8I26EEICfQeJ/9/MTeSFXkPLtN3dnHBdW2 kcyRrtdStWSxC8RWkqWPUNWlME3qG8puExFokU3mK3rCx80wCoje5FHMX1eAUWRbhZUl WXDEAJSGkIoHjUv82jvJezJXv3cs+50iykth/5T9Lh1j5Vfm13+XEN1hhH5L8Htm7Ixt nROw== X-Gm-Message-State: AOAM532GZxZcB4/iKe0WtLTXTtXNTK8jf9fv1RxoZPvtonzEWUJs5rw3 bEeH1d56z+RDPkd41Ls/tIcjaw== X-Google-Smtp-Source: ABdhPJyHjPXLqCvqDObzFK/W9oBLfHISCwFSn0P1fCWwLTTnMNCAAHYK9tDoO23Wv3td0RuLCQXbrQ== X-Received: by 2002:a37:741:: with SMTP id 62mr36166208qkh.495.1593805804983; Fri, 03 Jul 2020 12:50:04 -0700 (PDT) Received: from perhan.alvh.no-ip.org ([190.95.18.252]) by smtp.gmail.com with ESMTPSA id b10sm10738798qkh.124.2020.07.03.12.50.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jul 2020 12:50:04 -0700 (PDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id B01B52A25A1; Fri, 3 Jul 2020 15:50:02 -0400 (-04) Date: Fri, 3 Jul 2020 15:50:02 -0400 From: Alvaro Herrera To: Bruce Momjian Cc: Peter Geoghegan , Justin Pryzby , Tomas Vondra , Robert Haas , Andres Freund , David Rowley , Jeff Davis , Melanie Plageman , PostgreSQL Hackers Subject: Re: Default setting for enable_hashagg_disk (hash_mem) Message-ID: <20200703195002.GA28095@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200703140808.GE26235@momjian.us> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-Jul-03, Bruce Momjian wrote: > Well, the bottom line is that we are designing features during beta. Well, we're designing a way for users to interact the new feature. The feature itself is already in, and it works well in general terms. I expect that the new behavior is a win in the majority of cases, and the problem being discussed here will only manifest as a regression in corner cases. (I don't have data to back this up, but if this weren't the case we would have realized much earlier). It seem to me we're designing a solution to a problem that was found during testing, which seems perfectly acceptable to me. I don't see grounds for reverting the behavior and I haven't seen anyone suggesting that it would be an appropriate solution to the issue. > If we add a new behavior to PG 13, we then have the pre-PG 13 behavior, > the pre-patch behavior, and the post-patch behavior. How are people > supposed to test all of that? They don't have to. We tell them that we added some new tweak for a new pg13 feature in beta3 and that's it. > Add to that that some don't even feel we > need a new behavior, which is delaying any patch from being applied. If we don't need any new behavior, then we would just close the open item and call the current state good, no? -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services