From: | "Creager, Robert S" <CreagRS(at)LOUISVILLE(dot)STORTEK(dot)COM> |
---|---|
To: | "'Stephan Szabo'" <sszabo(at)megazone23(dot)bigpanda(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | sqllist <pgsql-sql(at)postgresql(dot)org> |
Subject: | RE: cannot get CREATE TABLE AS to work |
Date: | 2001-03-09 20:59:22 |
Message-ID: | 10FE17AD5F7ED31188CE002048406DE8514CED@lsv-msg06.stortek.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
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);
> ]
>
From | Date | Subject | |
---|---|---|---|
Next Message | Stephan Szabo | 2001-03-09 21:26:26 | RE: cannot get CREATE TABLE AS to work |
Previous Message | Stephan Szabo | 2001-03-09 20:15:30 | Re: cannot get CREATE TABLE AS to work |