pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedCREATE TRIGGER ... FOR EACH STATEMENT
2+ messages / 1 participants
[nested] [flat]
* CREATE TRIGGER ... FOR EACH STATEMENT
@ 2004-11-04 22:16 Mischa Sandberg <ischamay.andbergsay@activestateway.com>
2004-11-05 03:27 ` Re: CREATE TRIGGER ... FOR EACH STATEMENT Mischa Sandberg <ischamay.andbergsay@activestateway.com>
0 siblings, 1 reply; 2+ messages in thread
From: Mischa Sandberg @ 2004-11-04 22:16 UTC (permalink / raw)
To: pgsql-sql
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?
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: CREATE TRIGGER ... FOR EACH STATEMENT
2004-11-04 22:16 CREATE TRIGGER ... FOR EACH STATEMENT Mischa Sandberg <ischamay.andbergsay@activestateway.com>
@ 2004-11-05 03:27 ` Mischa Sandberg <ischamay.andbergsay@activestateway.com>
0 siblings, 0 replies; 2+ messages in thread
From: Mischa Sandberg @ 2004-11-05 03:27 UTC (permalink / raw)
To: pgsql-sql
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?
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2004-11-05 03:27 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2004-11-04 22:16 CREATE TRIGGER ... FOR EACH STATEMENT Mischa Sandberg <ischamay.andbergsay@activestateway.com>
2004-11-05 03:27 ` Mischa Sandberg <ischamay.andbergsay@activestateway.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox