Martijn Tonies wrote:

>>>> Incidentally, there's a trick for constraints. Execute each constraint
>>>> at row level. If it passes, fine. Otherwise track the row id. At
>>>> commit time, re-evaluate the failures and act accordingly. This is
>>>> probably significantly faster than performing all constraint checks at
>>>> commit time.
>> M> Can't this fail for CHECK constraints that include some kind of
>> M> check on multiple rows or existence of rows?
>>
>> and for FKs as well, not to mention self-reference for that matter.
>>
>> That's why you retry the failed ones at the end, as I understand.
>
> Hm, but a CHECK can be fine for a single row (while importing),
> but not meet the constraint afterwards.

How? We do not allow (or recommend?) accessing data from the other
rows/tables in CHECK constraint...

But at the moment I have a problem understanding why we're discussing
how to apply constraints _during: the load, since the original idea was
to evaluate them _after_ the load (though I do not have profiling
numbers from Vlad, some maybe indeed CHECK constrainsts can be evaluated
during the load).

Roman