X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id A84433A3ADC for ; Fri, 5 Nov 2004 03:54:07 +0000 (GMT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 33242-07 for ; Fri, 5 Nov 2004 03:53:50 +0000 (GMT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by svr1.postgresql.org (Postfix) with ESMTP id 051273A1D99 for ; Fri, 5 Nov 2004 03:53:53 +0000 (GMT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.12.9/8.12.9) with ESMTP id iA53rnJ7036441 for ; Fri, 5 Nov 2004 03:53:49 GMT (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.12.9/8.12.9/Submit) id iA53RdJu030277 for pgsql-sql@postgresql.org; Fri, 5 Nov 2004 03:27:39 GMT From: Mischa Sandberg Reply-To: ischamay.andbergsay@activestateway.com User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 X-Newsgroups: comp.databases.postgresql.sql Subject: Re: CREATE TRIGGER ... FOR EACH STATEMENT References: <1Txid.94791$9b.89312@edtnps84> In-Reply-To: <1Txid.94791$9b.89312@edtnps84> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 19 Message-ID: Date: Fri, 05 Nov 2004 03:27:44 GMT To: pgsql-sql@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.1 tagged_above=0.0 required=5.0 tests=NO_DNS_FOR_FROM X-Spam-Level: * X-Archive-Number: 200411/62 X-Sequence-Number: 19381 Please ignore this, I just caught up with news in c.d.p.hackers Mischa Sandberg wrote: > I notice a dearth of description of the FOR EACH STATEMENT flavour of > triggers, even though OLD_TABLE and NEW_TABLE are mentioned. > > After years of Sybase & MSSQL, being able to deal with the entire > INSERTED/DELETED rowsets in a trigger, rather than nibbling away > row by row, has been a great efficiency boost. In fact, the only I've > resorted to FOR EACH ROW triggers is where joining OLD_TABLE and > NEW_TABLE by primary key burned the CPU --- both pseudo-tables being > very large in some updates, and perforce having no indexes ... > > I can see from src/backend/command/trigger.c that > ExecASInsertTriggers() would have a hard time getting at the equivalent > of OLD_TABLE and NEW_TABLE, ExecBSInsertTriggers even worse. > > Anyone else out there who feels this would be a significant > enhancement?