Well, that explains why I wasn't seeing any appreciable speed increase with
the INITIALLY DEFERRED. I tried mucking in pg_class, and saw a 3 fold
increase in insert speed on inserts into my table with 2 relational
triggers. SET CONSTRAINTS ALL DEFERRED does nothing to very little to
increase the insertion speed. 15min 'INITIALLY DEFERRED' vs 13min 'ALL
DEFERRED' vs 5min 'pg_class update'. And that 15 vs 13 could be machine
activity.
I'll appologize to anyone trying to follow this one sided converstion, as I
wasn't paying attention to the e-mail headers and though Josh was replying
to me only.
Cheers,
Rob
> -----Original Message-----
>
> Well, you can always add deferrable initially immediate to
> the constraint
> and run a SET CONSTRAINTS ALL DEFERRED, but I'm not sure
> that'll actually
> be much faster, it still does a check per row I believe.
>
> It's hacky, but I'd say, if you don't have other triggers you
> care about,
> twiddle pg_class.reltriggers for the class to 0, do the insert, set it
> back to what it was before and then run selects to make sure
> the data is
> valid (ie, would the constraint have failed).
>
> [
> assuming one column, something like:
>
> select * from fktable where not exists
> (select * from pktable where pktable.pkcol=fktable.fkcol);
> ]
>
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
