Simon Riggs <si...@2ndquadrant.com> writes:
> 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.
I don't believe that it's a good idea to consider nextval() to be
reorderable, so I'm not convinced by your argument here.
> 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.
And I don't want to invent impossible-to-verify function attributes with
such a tiny use-case as this.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
