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 1sehmG-00Auto-Db for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Aug 2024 21:13:00 +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 1sehmE-001ROT-QL for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Aug 2024 21:12:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sehmE-001ROL-Gz for pgsql-hackers@lists.postgresql.org; Thu, 15 Aug 2024 21:12:58 +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 1sehmC-0052yL-2k for pgsql-hackers@postgresql.org; Thu, 15 Aug 2024 21:12:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us; s=2024011501; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description; bh=EK9AiLPB/bJzB9D5RPwNNkYr5QYd/BvCmbGMpODoWHc=; b=gFq4F tRHjaXC+3xcf+LuDE/2zo9UGKV/5O5KvrTSFoYyZOm6MnrrsFUlJ4ufylcWZv/Gbwi4kqmPvQvcnG rlYrDdfXwZOWxHNtAifBJoZxxUDhS5DXWKOIwO1Z4/W8PLznqExuX4v1LUdgC1VqmGjhDUQ9eu8dl GutwQlebsXyxXGE2z7Lhjb45KW7OkDF9ae+xWqXvIwPPvH6dMBs/cStLSfXKKLv+KcnTsL4D9sfnT yARJVve+MfIZGJuvt01N2no6rZ2mV8gSs8mHGL/hK6Ub5od1iYGrDxEceNn4gXU29Hk3J50g60VQ7 T+Aoz8ruXqRQDTox0K0eIRVofXtzg==; Received: from bruce by momjian.us with local (Exim 4.96) (envelope-from ) id 1sehm6-00FRDe-2F; Thu, 15 Aug 2024 17:12:50 -0400 Date: Thu, 15 Aug 2024 17:12:50 -0400 From: Bruce Momjian To: Jelte Fennema-Nio Cc: "Fujii.Yuki@df.MitsubishiElectric.co.jp" , PostgreSQL-development , Robert Haas , Tom Lane , Stephen Frost , Andres Freund , Tomas Vondra , Julien Rouhaud , Daniel Gustafsson , vignesh C , Alexander Pyhalov Subject: Re: Partial aggregates pushdown Message-ID: References: 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 Thu, Aug 8, 2024 at 01:48:49PM +0200, Jelte Fennema-Nio wrote: > SUMMARY OF THREAD > > The design of patch 0001 is agreed upon by everyone on the thread (so > far). This adds the PARTIAL_AGGREGATE label for aggregates, which will > cause the finalfunc not to run. It also starts using PARTIAL_AGGREGATE > for pushdown of aggregates in postgres_fdw. In 0001 PARTIAL_AGGREGATE > is only supported for aggregates with a non-internal/pseudo type as > the stype. > > The design for patch 0002 is still under debate. This would expand on > the functionality added by adding support for PARTIAL_AGGREGATE for > aggregates with an internal stype. This is done by returning a byte > array containing the bytes that the serialfunc of the aggregate > returns. > > A competing proposal for 0002 is to instead change aggregates to not > use an internal stype anymore, and create dedicated types. The main > downside here is that infunc and outfunc would need to be added for > text serialization, in addition to the binary serialization. An open > question is: Can we change the requirements for CREATE TYPE, so that > types can be created without infunc and outfunc. > > WHAT IS NEEDED? > > The things needed for this patch are that docs need to be added, and > detailed codereview needs to be done. > > Feedback from more people on the two competing proposals for 0002 > would be very helpful in making a decision. First, I am sorry to be replying so late --- I have been traveling for the past four weeks. Second, I consider this feature a big part of sharding, and I think sharding is Postgres's biggest missing feature. I talk about this patch often when asked about what Postgres is working on. Third, I would like to show a more specific example to clarify what is being considered above. If we look at MAX(), we can have FDWs return the max for each FDW, and the coordinator can chose the highest value. This is the patch 1 listed above. These can return the pg_aggregate.aggtranstype data type using the pg_type.typoutput text output. The second case is for something like AVG(), which must return the SUM() and COUNT(), and we currently have no way to return multiple text values on the wire. For patch 0002, we have the option of creating functions that can do this and record them in new pg_attribute columns, or we can create a data type with these functions, and assign the data type to pg_aggregate.aggtranstype. Is that accurate? -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.