Re: Frontend/Backend protocol changes?

Hey Tom,

"Tom Lane" <tgl@sss.pgh.pa.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.

Ok.

> 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
> doing?

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
the end.

If there's a better way to do this, I'd happily remove the trigger.

Thanks,
jas.
--
 CREATE OR REPLACE FUNCTION audit () RETURNS OPAQUE AS '     DECLARE        ts TIMESTAMP := ''now'';        new_audit
INT4:= nextval(''"GENEX_ID_SEQ"''::text);     BEGIN        IF TG_OP = ''INSERT'' THEN          INSERT INTO Audit_view
(audit_pk, modification_date, modified_by)                      VALUES (new_audit, ts, user());        ELSE
/*for UPDATE we keep a trail of audits */          INSERT INTO Audit_view
(audit_pk,audit_fk,modification_date,modified_by)                     VALUES (new_audit,OLD.audit_fk,ts,user());
ENDIF;         UPDATE tableadmin SET audit_fk = new_audit               WHERE UPPER(table_name) =
UPPER(text(TG_RELNAME));        NEW.audit_fk := new_audit;        RETURN NEW;     END; ' LANGUAGE 'plpgsql';