Re: Frontend/Backend protocol changes?

Hey Tom,

"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.

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());
END IF;

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';