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 1m6cPb-0006jR-6a for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Jul 2021 17:23:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m6cPZ-0004LO-Vz for pgsql-hackers@arkaria.postgresql.org; Thu, 22 Jul 2021 17:23:05 +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 1m6cPZ-0004Dw-Lo for pgsql-hackers@lists.postgresql.org; Thu, 22 Jul 2021 17:23:05 +0000 Received: from mxout2.routing.net ([2a03:2900:1:a::b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m6cPW-0001LX-K4 for pgsql-hackers@lists.postgresql.org; Thu, 22 Jul 2021 17:23:04 +0000 Received: from mxbox2.masterlogin.de (unknown [192.168.10.89]) by mxout2.routing.net (Postfix) with ESMTP id 9CD055FA21; Thu, 22 Jul 2021 17:22:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailerdienst.de; s=20200217; t=1626974578; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=D2VICNvrhXRbolkusd5Yz6cQ6JHi6c3Hi/Wlsd5rBvg=; b=nopQd2C9vlw7eejWHXpMmaXpbcIg89W+vE9epjAakbJMRwem8ESB/6y8tkyDBJ2TifoZsd 6wMlEbYtNgueyNoFCZkbrHNqQTrlJ3oMAKRB7MJtTBY4+Q7H947V6n5nxR1GwQCrhmTDHP FEltDh4c6obfSMkYvqKxwfZly/cIqUM= Received: from remote.index.de (p578a9a34.dip0.t-ipconnect.de [87.138.154.52]) by mxbox2.masterlogin.de (Postfix) with ESMTPSA id 22C4B100532; Thu, 22 Jul 2021 17:22:58 +0000 (UTC) Received: from acedia.index-gruppe.local (192.168.3.121) by acedia.index-gruppe.local (192.168.3.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 22 Jul 2021 19:22:57 +0200 Received: from acedia.index-gruppe.local ([fe80::d96c:8551:78c8:d947]) by acedia.index-gruppe.local ([fe80::d96c:8551:78c8:d947%13]) with mapi id 15.01.2176.014; Thu, 22 Jul 2021 19:22:57 +0200 From: Arne Roland To: Alvaro Herrera CC: vignesh C , Zhihong Yu , Pg Hackers Subject: Re: Rename of triggers for partitioned tables Thread-Topic: Rename of triggers for partitioned tables Thread-Index: AQHWxEk1+rora/wutkWbcRQhC03q0KnbGQ2sgAAECBOATmSTgIBhAeKAgBDG6bOAACCNT4AAKOcAgAAj1kP///tHgIAEsSJngAHhzjCAhX9QJP//43kAgAAjD3T///1iAABXUKhwA1bKhQAABHSL9QDdrxEAAARjdxL///exAIABN1SAgAG0zACAASTOjIAACgeAgAAiw8U= Date: Thu, 22 Jul 2021 17:22:57 +0000 Message-ID: <29dca60bc79e4c2ab26fa328a94b1289@index.de> References: <724b9f97a96c470aab3bfee502366b7c@index.de>,<202107221620.vrxflq2i5y7l@alvherre.pgsql> In-Reply-To: <202107221620.vrxflq2i5y7l@alvherre.pgsql> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.1.33] Content-Type: multipart/alternative; boundary="_000_29dca60bc79e4c2ab26fa328a94b1289indexde_" MIME-Version: 1.0 X-Mail-ID: 9c848f68-9b97-482c-9194-daf948e07db8 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_29dca60bc79e4c2ab26fa328a94b1289indexde_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: Alvaro Herrera Sent: Thursday, July 22, 2021 18:20 To: Arne Roland Subject: Re: Rename of triggers for partitioned tables If we have good use for such an index, I don't see why we can't add it. But I'm not sure that it is justified -- certainly if the only benefit is to make ALTER TRIGGER RENAME recurse faster on partitioned tables, it is not justified. Speed is not really the issue here, most people will have under 20 triggers= per table anyways. I think even the simpler code would be worth more than = the speed gain. The main value of such an index would be the enforced uniqu= eness. I just noticed that apparently the ALTER TABLE [ IF EXISTS ] [ ONLY ] name [ ENABLE | DISABLE ] TRIGGER ... syntax albeit looking totally different and it already recurses, it has pre= cisely the same issue with pg_dump. In that case the ONLY syntax isn't opti= onal and the 2. from your above post does inevitably apply. Since it is sort of the same problem, I think it might be worthwhile to add= ress it as well within this patch. Adding two to four ereports doesn't soun= d like scope creeping to me, even though it touches completely different co= de. I'll look into that as well. Regards Arne --_000_29dca60bc79e4c2ab26fa328a94b1289indexde_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


From: Alvaro Herrera <alvherre@alvh.no-ip.org>
Sent: Thursday, July 22, = 2021 18:20
To: Arne Roland
Subject: Re: Rename of triggers for partitioned tables
 
If we have go= od use for such an index, I don't see why we can't add it.
But I'm not sure = that it is justified -- certainly if the only benefit
is to make ALTER TRIGGER RENAME recurse fa= ster on partitioned tables, it
is not justified.

Speed is not real= ly the issue here, most people will have under 20 triggers per table anyway= s. I think even the simpler code would be worth more than the speed gain. T= he main value of such an index would be the enforced uniqueness.

I just noticed th= at apparently the
ALTER TABLE [ IF = EXISTS ] [ ONLY ] name [ ENABLE | DISABLE ] TRIGGER ...
syntax albe= it looking totally different and it already recurses, it has precisely the same i= ssue with pg_dump. In that case the ONLY syntax isn't optional and the 2. f= rom your above post does inevitably apply.

Since it is= sort of the same problem, I think it might be worthwhile to address it as = well within this patch. Adding two to four ereports doesn't sound like scop= e creeping to me, even though it touches completely different code. I'll look into that as well.

Regards
Arne

--_000_29dca60bc79e4c2ab26fa328a94b1289indexde_--