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 1qC00E-0002vY-BR for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Jun 2023 15:44:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qC00C-0007R7-63 for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Jun 2023 15:44:12 +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 1qC00B-0007Qy-Sh for pgsql-hackers@lists.postgresql.org; Wed, 21 Jun 2023 15:44:11 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qC004-003qRl-HC for pgsql-hackers@postgresql.org; Wed, 21 Jun 2023 15:44:11 +0000 Received: from bruce by momjian.us with local (Exim 4.94.2) (envelope-from ) id 1qBzzx-001zt6-2d; Wed, 21 Jun 2023 11:43:57 -0400 Date: Wed, 21 Jun 2023 11:43:57 -0400 From: Bruce Momjian To: Alexander Pyhalov Cc: "Fujii.Yuki@df.MitsubishiElectric.co.jp" , PostgreSQL-development , Andres Freund , Tom Lane , Tomas Vondra , Julien Rouhaud , Daniel Gustafsson , Ilya Gladyshev Subject: Re: Partial aggregates pushdown Message-ID: References: <8ffedecae0d21a3cd93805baf1dcc0de@postgrespro.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Jun 20, 2023 at 09:59:11AM +0300, Alexander Pyhalov wrote: > > Therefore, it seems like it would be near-zero cost to just call conn = > > GetConnection() and then PQserverVersion(conn), and ReleaseConnection(). > > You can then use the return value of PQserverVersion() to determine if > > you can push down partial aggregates. > > Hi. > Currently we don't get remote connection while planning if > use_remote_estimate is not set. > Such change would require to get remote connection in planner, not in > executor. > This can lead to change of behavior (like errors in explain when user > mapping is wrong - e.g. bad password is specified). > Also this potentially can lead to establishing connections even when plan > node is not actually used > (like extreme example - select sum(score) from t limit 0). > I'm not saying we shouldn't do it - just hint at possible consequences. Agreed. I noticed it was doing FDW connections during optimization, but didn't see the postgres_fdw option that would turn it off. Interestingly, it is disabled by default. After considering the options, I think we should have a postgres_fdw option called "planner_version_check", and default that false. When false, a remote server version check will not be performed during planning and partial aggregates will be always be considered. When true, a version check will be performed during planning and partial aggregate pushdown disabled for pre-PG 17 foreign servers during the query. If we want to be more specific, we can call it "check_partial_aggregate_support". -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.