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 1q6pl1-00032i-Ai for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Jun 2023 09:47:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1q6pl0-0000ab-4f for pgsql-hackers@arkaria.postgresql.org; Wed, 07 Jun 2023 09:47:10 +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 1q6pkz-0000aS-MM for pgsql-hackers@lists.postgresql.org; Wed, 07 Jun 2023 09:47:09 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by makus.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1q6pku-000giS-MX for pgsql-hackers@postgresql.org; Wed, 07 Jun 2023 09:47:08 +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 05F1FE20E4A; Wed, 7 Jun 2023 12:49:04 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1686131345; bh=n4CSJzauiaOYR9x9473qc4p1gy1cDOD2OJkpKvJMEtg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:User-Agent: Message-ID:From; b=uXBKUl0GNonl3wZWAxUxUoyw952pFzsfp/SileoRttk0PTvHnZx6GN3yWben7PP4X 2584El3BtMB3wuMPBtqMSQM9WaPVVD9zCDSMpJJb2iyO6n4RxpV4Nr7GdO5LNcrgXZ m963p1wsLRFFjxNCr+5emvTawzD1dzJqyyKgeTh88bcy6UTIzIip4uJ6GjasxueS1L hbP4FSKyOry0pAwaCLr5T73Nzxn0B8ShpHwyPq09Mycm8Gb8t1OMyamAkeuuk8LfCL RCjd0sKwFuJjTVlFqprVDOh5v+UH8vjJmw3NOBm/1SXnUdoELzUuRWxv5Kx7crKk7s xavuPV9E3panQ== MIME-Version: 1.0 Date: Wed, 07 Jun 2023 12:47:01 +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> User-Agent: Roundcube Webmail/1.4.11 Message-ID: <36f0ba8bf12a7285ca6ff51559f700db@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-06 15:31: > Thanks for the explanation. > I understand that the method of comparing two function name strings is > incorrect. > Instead, I added the parameter isaggpartialfunc indicating whether the > aggregate > function and its aggpartialfunc are the same or different. Hi. 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. Another issue - the patch misses recording dependency between aggpartialfn and aggregate procedure. -- Best regards, Alexander Pyhalov, Postgres Professional