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 1jwrO0-0006qr-DE for pgsql-hackers@arkaria.postgresql.org; Sat, 18 Jul 2020 18:16:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jwrNz-0007Qu-9L for pgsql-hackers@arkaria.postgresql.org; Sat, 18 Jul 2020 18:16:35 +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 1jwrNy-0007Qn-Uu for pgsql-hackers@lists.postgresql.org; Sat, 18 Jul 2020 18:16:35 +0000 Received: from mail-pf1-x42a.google.com ([2607:f8b0:4864:20::42a]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jwrNw-0005kK-NX for pgsql-hackers@postgresql.org; Sat, 18 Jul 2020 18:16:34 +0000 Received: by mail-pf1-x42a.google.com with SMTP id q17so6977302pfu.8 for ; Sat, 18 Jul 2020 11:16:32 -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=yv84DuleHKz1bcfkVWXf6HG8VWYqEj6prwKcKjRRlsY=; b=sVvkHE0a1tghQ7b/saT68aQvn1IeJLEfRfFjppZsEQ5ps/ySGGckGK6Tu3+rwz/bsg GLAEEGU4WGFP1IeQqr8HGDUBSk8hA0z5FobxlMNbVM4P/PzKNzkbLgoMJ77Tqi/3FBsK Fx4rm92g5e+LBJZkmvCQzVYgePzBCyvxryk0W7AHvcvWkw+JaJRVnY8qeaXnwkRlCLLh 6FzCWBfmwlatbOdbccvER+3NEhMMgsndfTgbUEy+p7V6xj4RzjGSuVPcOsPW7Xt+uIEM FSPEo2IIbD9bRSV6VgnIUB8TfODh95hKkl6SnDp9SwVqH7nDvPT+OJnldTVQeP4IYDIi bKOg== 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=yv84DuleHKz1bcfkVWXf6HG8VWYqEj6prwKcKjRRlsY=; b=Py+KdZdcclkFc4Z/8K5Wl1dsICpFo4DsCrYHmrV17AhkJCsumFykjG/MikFg3/U4Ly McYbXYi4noA40Tlf9jt4xIwXiNfvOdn3btV9n/n72hfZKD8ThhwYxLI+0DMkHe23ZRNu bmfb4mV+zlxWJR3laXtsVksTHIRH7559qjgBoxTdEPGywR1MARHuKOkDQ80FsHMeDquy CeiFnSmbqaoVKWspI8s848XKLSlOkHH0n35FcKJARgjRSAOdn8ncFFsqSHVFWoG6vIxx YG/7UKczD8/3F5g3kUNkRZUF/Sigy+z4DWxq0yhschcp9heOCyCKSKVnaA8hcwaZku/Q mh/g== X-Gm-Message-State: AOAM533iWifoxJbAGDGB2ZmbkBRuCIWfc4z3QzRGFA9YiWkN9N/7RSAh 8GEIwa7l717g/lOgUHinMTZKRA== X-Google-Smtp-Source: ABdhPJwbhipHc1eZ5RjTJOLL9u7o2MPx3qVcYMvLLuEOh6AFA5XRkAez8Lgdg8b35HGud8ZcUi1GBQ== X-Received: by 2002:a65:6089:: with SMTP id t9mr13549911pgu.236.1595096189572; Sat, 18 Jul 2020 11:16:29 -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 j16sm10647782pgb.33.2020.07.18.11.16.27 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sat, 18 Jul 2020 11:16:28 -0700 (PDT) Message-ID: <6d0aba397625df79bdc3ca85adc11b9e48ecb0da.camel@j-davis.com> Subject: Re: Default setting for enable_hashagg_disk From: Jeff Davis To: Peter Geoghegan Cc: Alvaro Herrera , David Rowley , Stephen Frost , Tom Lane , Andres Freund , Bruce Momjian , Robert Haas , Justin Pryzby , Melanie Plageman , Tomas Vondra , "pgsql-hackers@postgresql.org" Date: Sat, 18 Jul 2020 11:16:26 -0700 In-Reply-To: References: <5cf74833a830e76cc7cc7506aa77bd6ab0c94f4c.camel@j-davis.com> <20200713164736.GA25726@alvherre.pgsql> <9e4a4cffe3eee0543e5b94c90821d39e03b81d29.camel@j-davis.com> 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-17 at 18:38 -0700, Peter Geoghegan wrote: > There is also the separate question of what to do about the > hashagg_avoid_disk_plan GUC (this is a separate open item that > requires a separate resolution). Tom leans slightly towards removing > it now. Is your position about the same as before? Yes, I think we should have that GUC (hashagg_avoid_disk_plan) for at least one release. Clealy, a lot of plans will change. For any GROUP BY where there are a lot of groups, there was only one choice in v12 and now there are two choices in v13. Obviously I think most of those changes will be for the better, but some regressions are bound to happen. Giving users some time to adjust, and for us to tune the cost model based on user feedback, seems prudent. Are there other examples of widespread changes in plans where we *didn't* have a GUC? There are many GUCs for controlling parallism, JIT, etc. Regards, Jeff Davis