On 15 April 2013 16:24, David Fetter <david@fetter.org> wrote:
>> 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.
>
> Do you have numbers on this, or ways to gather same? In other words,
> how do we know what resources (time, CPU cycles, disk seeks, etc.) are
> being consumed here?
The multi-insert optimisation for COPY is already there and works well
enough to have been committed.
All we have to do to allow it to be used is to persuade COPY that come
kinds of volatile function need not prevent the optimisation. So once
we have a mechanism for appropriately labelling a function, it will be
a one-line change in copy.c to enable the optimisation.
--Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services