On Fri, 15 Aug 2003, Christopher Kings-Lynne wrote:This is clearly a case for a statement level trigger, as soon as affected rows can be identified.
theI throw last nights backup at it. Data went in in about 1/2 an hour then
I can also attest to the horrendously long time it takes to restore the ADDconstraints went in and they took at age. about 2 hours.....
Is there anyway to speed up the database constraint code? Because quite
frankly at the current speed your probably better off without the
constraints.... (Same problem with 7.3 come to think about it.)
FOREIGN KEY section...
That really needs to be rewritten to do a single check over the table rather than running the constraint for every row. I keep meaning to get around to it and never actually do. :( I'm not sure that in practice you'll get a better plan at restore time depending on what the default statistics give you.
One remark on that enable/disable triggers stuff: from a user's perspective, I wouldn't consider a constraint trigger as a trigger, so if I'd disable all triggers on a table, I still would expect all constraints to be checked.
Regards, Andreas
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html