On 15.04.2013 17:00, Simon Riggs wrote:
> COPY cannot be optimised correctly if we have before triggers or
> volatile default expressions.
>
> The multi-insert code detects those cases and falls back to the single
> row mechanism in those cases.
>
> There a common class of volatile functions that wouldn't cause
> problems: any volatile function that doesn't touch the table being
> loaded and still works correctly when called with alternately ordered
> data.
>
> I claim this is a common class, since sequence next_val functions and
> uuid generators meet that criteria and most common forms of auditing
> trigger, as well as any other form of data-reformatting trigger. Since
> this is a common case, it seems worth optimising.
>
> What I'd like to do is to invent a new form of labelling that allows
> us to understand that COPY can still be optimised.
It would be even nicer to detect at runtime, when a default expression
or before trigger tries to access the same table. When that happens, we
could immediately flush all the tuples buffered that far to disk, so
that they are visible to the expression, and then proceed with it.
- Heikki
