Thread: CHECK constraints in pg_dump
Hi guys, I notice that we're still dumping CHECK constraints as part of the CREATE TABLE statement, and not as an ALTER TABLE statement after the data has been loaded. Should we move it to after the data for speed purposes, like we have with all other constraints? Chris
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> I notice that we're still dumping CHECK constraints as part of the CREATE
> TABLE statement, and not as an ALTER TABLE statement after the data has been
> loaded.
> Should we move it to after the data for speed purposes, like we have with
> all other constraints?
Why would there be any speed advantage?
regards, tom lane
> "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes: > > I notice that we're still dumping CHECK constraints as part of the CREATE > > TABLE statement, and not as an ALTER TABLE statement after the data has been > > loaded. > > > Should we move it to after the data for speed purposes, like we have with > > all other constraints? > > Why would there be any speed advantage? Is it not faster to add it when all the data is there, rather than evaluating it as each row is inserted, like indexes? Chris
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
>> Why would there be any speed advantage?
> Is it not faster to add it when all the data is there, rather than
> evaluating it as each row is inserted, like indexes?
I don't see why. There are good algorithmic reasons why bulk-loading
an index is faster than retail insertions --- mainly that btree goes
out of its way to make it so, with a special code path. But I see
no reason why checking a constraint expression is going to be any
faster as a post-pass than when done while loading the data. If
anything, I'd guess it to be slower because you have to re-read the
table.
regards, tom lane
On Wed, 2003-02-26 at 14:54, Tom Lane wrote: > "Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes: > >> Why would there be any speed advantage? > > > Is it not faster to add it when all the data is there, rather than > > evaluating it as each row is inserted, like indexes? > > I don't see why. There are good algorithmic reasons why bulk-loading > an index is faster than retail insertions --- mainly that btree goes > out of its way to make it so, with a special code path. But I see > no reason why checking a constraint expression is going to be any > faster as a post-pass than when done while loading the data. If > anything, I'd guess it to be slower because you have to re-read the > table. One reason for delaying constraint checks until after all data is loaded is that any CHECK constraints against other tables must be hidden in functions. For example, we cannot say: CHECK (col1 > othertable.col2 WHERE id = othertable.id). Since such checks are hidden, I suppose it will not be possible to arrange the order of loading in pg_dump to ensure that such checks succeed; therefore it would be better for any check constraint involving a function to be delayed till after all data is loaded. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "These things have I written unto you that believe on the name of the Sonof God; that ye may know that ye have eternal life, and that ye may believe on the name of the Son of God." I John 5:13