"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> I dunno who the heck you got that advice from, but *none* of those
> statements are correct, at least not in recent PG releases.
Well, that's refreshing.
> You definitely want to do lots of inserts per transaction. There's
> probably not much further improvement to be had beyond a thousand or so
> rows per transaction, though.
OK, that's good, too.
> COPY is faster than a series of INSERTs because you bypass the
> parsing and planning overhead needed for each insert.
> But my suspicion is that the cycles are actually going into your
> triggers. What triggers have you got on this table, and what are they
Just one trigger, it tracks who inserted the row and when, and adds
this as a row to the Audit table. I keep an audit trail, so that if
it's an update (which it isn't in the case I'm writing about) I chain
the most recent audit to the previous one. I'm including the code at
If there's a better way to do this, I'd happily remove the trigger.
CREATE OR REPLACE FUNCTION audit () RETURNS OPAQUE AS '
ts TIMESTAMP := ''now'';
new_audit INT4 := nextval(''"GENEX_ID_SEQ"''::text);
IF TG_OP = ''INSERT'' THEN
INSERT INTO Audit_view (audit_pk, modification_date, modified_by)
VALUES (new_audit, ts, user());
/* for UPDATE we keep a trail of audits */
INSERT INTO Audit_view (audit_pk,audit_fk,modification_date,modified_by)
UPDATE tableadmin SET audit_fk = new_audit
WHERE UPPER(table_name) = UPPER(text(TG_RELNAME));
NEW.audit_fk := new_audit;
' LANGUAGE 'plpgsql';
In response to
pgsql-interfaces by date
|Next:||From: Jason E. Stewart||Date: 2002-11-22 21:34:20|
|Subject: Re: Frontend/Backend protocol changes?|
|Previous:||From: Tom Lane||Date: 2002-11-22 17:01:34|
|Subject: Re: Frontend/Backend protocol changes? |