Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uQzvL-004Fie-RU for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Jun 2025 02:50:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uQzvJ-00EsDM-F3 for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Jun 2025 02:50:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uQzvJ-00EsDE-5H for pgsql-hackers@lists.postgresql.org; Mon, 16 Jun 2025 02:50:13 +0000 Received: from mail-lf1-x12a.google.com ([2a00:1450:4864:20::12a]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uQzvI-002Drj-03 for pgsql-hackers@lists.postgresql.org; Mon, 16 Jun 2025 02:50:12 +0000 Received: by mail-lf1-x12a.google.com with SMTP id 2adb3069b0e04-553644b8f56so4058354e87.1 for ; Sun, 15 Jun 2025 19:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750042210; x=1750647010; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Syxh1rI+JuxMgeyD5a5jDhqX/Epwy24onSo3iaO7AOI=; b=Vgz+JDmR6Q3f4XRcFuHZLeY/OIyKy3DPt7UhfvXU2DmaOm+vOyna61+unBUFRSVxNm 29pRjG/hottNw39iECI8hWS5137BhzitYRdz5CGN6z1G6zRebp6Ykf/YcsXyOqddCdzU joCTnbMgCxX9+cbQThxPI0Zbz7Q4V1JMLQHxkAU6culk4dqdeyGvKkLUeB8fmss6CDuc kOlhtgSsVGJUVW2OFJc4lWIgzIX/2ZXXrUVpsaiylCoObajfgCOjZIE9FDxQ9eWDBBLt st2nXS5ZaYMS/IYGKtb9XjAmUQa6bp3eiX9FBNd/NgaIhvPmBBBH6aBwFHIrciqqxmKy 2cNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750042210; x=1750647010; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Syxh1rI+JuxMgeyD5a5jDhqX/Epwy24onSo3iaO7AOI=; b=e7N9vG5CqPkgCc+HdgRaDR+H63EgbM99bN69ZE+uoGzwGaeyGFLpFab2kmYhX3TI7Q w0gAwbvEz2KkmH0upDWV60A6NJmZeaTU6Jl9U7v9wGRxo4Chamc6AeRsGAEjd6KPzaC1 4Erb0ftmMmvVR/92VLlAbZw3MIu3A+HHc1gJZ5B6SO+wO9WKX6FwBJzYSEN9MgEeBAGG gWPLTH8NvP/1GzNdV9iITbdOTT34wZNrS9y2auMASzyeTBal+uiAgaptdmas7ac8f6W2 LdiKkmFwMzSsRsof0HiDs0bpqStgC5dX85pT7wt9XkdVf+W1dl/j1jKuzPACXot8bo8z e52w== X-Forwarded-Encrypted: i=1; AJvYcCUZXLRUN6IYIcAjMEfcNeChCsu7UEZoz3G+QxmIH8TjJBKD7u/eExZIXPcN9WJkanTVAh6Rf8F+nY0gE46i@lists.postgresql.org X-Gm-Message-State: AOJu0Yy1jBe7UnNX6hr+ljW2dIad2YC5yi6+gJi9KD3fgZNAC8R3TA1K 9lKoApsLl4UBekQV0hXWwBF5kjqKUaAsdoSbrWI/lD3+wqEBho5Oa6gB1cDdt82VrV9IkVXMkVC p0jCExAF3c0EI0A+4f73Wnk0T8hdRRH4= X-Gm-Gg: ASbGncv5s7NY/rz7vQohKsMgQq4xAZaq2sQNXGP+PkiTWXvGriZbmCpG8mRoElt1rSk FmWaMfY8Y3/QFfEh1H8pllnSzKY37uD1Bm4+fEOAXHc0oCukH0yE3FtliUG/Gw4A/fEADs+qDip 9OwX+tht6dtxzQfEhQPjGAySa1iamMX+C/ezQUEQQrxjnJiMIJCRBho0NSwUAix7uryYR6geALn OFWtQ== X-Google-Smtp-Source: AGHT+IEvSQ9JIO8yxpAdQ7BQn2+Kk2jaICWpWboG4fXOy7pt+RIZ5qedR4z8la67yG0p99hvnEy/TKG/UlSpsoGNWmU= X-Received: by 2002:a05:6512:158b:b0:553:5140:c8af with SMTP id 2adb3069b0e04-553b6daa7f6mr1714377e87.0.1750042209753; Sun, 15 Jun 2025 19:50:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Rowley Date: Mon, 16 Jun 2025 14:49:57 +1200 X-Gm-Features: AX0GCFuVJRAM2hP60IOqRQg6_BFEtFQUgHxpjU1K3Lz0TaYN3j3BymebwQsGkvU Message-ID: Subject: Re: Add enable_groupagg GUC parameter to control GroupAggregate usage To: Tatsuro Yamada Cc: Ashutosh Bapat , pgsql-hackers@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, 11 Jun 2025 at 20:37, Tatsuro Yamada wrote: > I created a regression test to check the enable_groupagg parameter in > the new patch. > To ensure plan stability, I disabled parallel query by setting the max_parallel_* > parameters to 0. > > Any feedback is welcome. Typically, in the regression tests we've used enable_sort to force a HashAgg. There are certainly times when that's not good enough and you might also need to disabe enable_indexscan too, so I understand the desire to add this GUC. It's probably going to be worth going over the regression tests to find where we use enable_sort to disable GroupAgg and replace those with your new GUC. Otherwise, people looking at those tests in the future will be a bit confused as to why the test didn't just SET enable_groupagg TO false; These will likely be good enough to serve as your test, rather than creating a new table to test this feature. I think you should also look at create_setop_path(), as I imagine that the same arguments for using enable_hashagg in that function apply equally to enable_groupagg. + if (aggstrategy == AGG_SORTED && !enable_groupagg && enable_hashagg) + ++disabled_nodes; This code looks a bit strange. You're only going to disable it if hash agg is enabled? If they're both disabled, let add_path() decide. Anyone who complains that they didn't get the aggregate type they wanted with both enable_hashagg and enable_groupagg set to off hasn't got a leg to stand on. David