Roman Rokytskyy wrote:

> 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).
>
>

We're discussing that because it can be made to work, evaluation at row
time is faster (everything you need is in cache) and easier (less code).