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 1q7AFB-00029o-9y for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Jun 2023 07:39:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q7AF8-000274-81 for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Jun 2023 07:39:38 +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 1q7AF7-00026o-Oq for pgsql-hackers@lists.postgresql.org; Thu, 08 Jun 2023 07:39:37 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by makus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1q7AF3-000r06-Or for pgsql-hackers@postgresql.org; Thu, 08 Jun 2023 07:39:36 +0000 Received: from mail.postgrespro.ru (webmail.mstn.postgrespro.ru [192.168.2.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: a.pyhalov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id 7C8DAE20C31; Thu, 8 Jun 2023 10:41:37 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1686210097; bh=GI9E6KH6guWGW8EQGq0H96npGKicdFhyudavz7q4zTU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:User-Agent: Message-ID:From; b=nPnhRQBSfBJHOg0La45zkzuKkgFB+nPpDISzKNimDeoGkGzIjbx+wn9WDUezgr+nD 6CRjEyaBQvh2g5k9I+e5h6LEsrS5IAzddmm37nFvNsEtLAux/9AYha5+oMPIUEe4Pn WSqlCst1cHZzrW4BRDqEqxeCYBa/FqCfhF/WEtaeYpXnbfGGONudoMnpB0JPe2BDZm CNpvTNseRjdA6l5eOve4COKJ0yQs6A7CTqbS9Nj1t5DtealUEC/2fpNm6+V05yOM0m kIOohmbJcOaViLUSoJqGLfj9+xFwvMBR7w/ASwFacnAaY/AmYtEhfiTwWPR+q4sue4 IBNtfOSZ10Nig== MIME-Version: 1.0 Date: Thu, 08 Jun 2023 10:39:30 +0300 From: Alexander Pyhalov To: "Fujii.Yuki@df.MitsubishiElectric.co.jp" Cc: Bruce Momjian , PostgreSQL-development , Andres Freund , Tom Lane , Tomas Vondra , Julien Rouhaud , Daniel Gustafsson , Ilya Gladyshev Subject: Re: Partial aggregates pushdown In-Reply-To: References: <8ffedecae0d21a3cd93805baf1dcc0de@postgrespro.ru> <93fc7f04f8c6978296c05f4f70671a43@postgrespro.ru> <36f0ba8bf12a7285ca6ff51559f700db@postgrespro.ru> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <0a3960c36e705dccfce667f04f0bf632@postgrespro.ru> X-Sender: a.pyhalov@postgrespro.ru Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Fujii.Yuki@df.MitsubishiElectric.co.jp писал 2023-06-08 02:08: >> From: Alexander Pyhalov >> Sent: Wednesday, June 7, 2023 6:47 PM >> This seems to be more robust, but the interface became more strange. >> I'm not sure what to do with it. Some ideas I had to avoid introducing >> this >> parameter. Not sure I like any of them. >> >> 1) You can use QualifiedNameGetCreationNamespace() for >> aggpartialfnName >> and still compare namespace and function name for it and aggName, >> aggNamespace. >> Seems to be not ideal, but avoids introducing new parameters. >> >> 2) You can lookup for partial aggregate function after >> ProcedureCreate() in >> AggregateCreate(), if it wasn't found at earlier stages. If it is the >> aggregate itself >> - check it. If it's still not found, error out. Also seems to be a bit >> ugly - you leave >> uncommitted garbage for vacuum in catalogue. > Thank you for suggesting alternatives. > The disadvantages of alternative 2) appear to be undesirable, > I have modified it according to alternative 1) > >> Another issue - the patch misses recording dependency between >> aggpartialfn >> and aggregate procedure. > I added code to record dependencys between aggpartialfn > and aggregate procedure, similar to the code for functions such as > combinefunc. > Hi. Looks better. The only question I have is should we record dependency between procOid and aggpartialfn if aggpartialfn == procOid. Also it seems new code likely should be run through pgindent. doc/src/sgml/postgres-fdw.sgml: + For WHERE clauses, + JOIN clauses, this sending is active if + conditions in + hold and enable_partitionwise_join is true(this condition + is need for only JOIN clauses). + For aggregate expressions, this sending is active if conditions in No space between "true" and "(" in "is true(this condition". Some sentences in documentation, like one starting with "For aggregate expressions, this sending is active if conditions in..." seem to be too long, but I'm not the best man to read out documentation. In "Built-in sharding in PostgreSQL" term "shard" doesn't have a definition. By the way, I'm not sure that "sharding" documentation belongs to this patch, at least it needs a review from native speaker. -- Best regards, Alexander Pyhalov, Postgres Professional