On Mon, Apr 15, 2013 at 11:49:42AM -0400, Tom Lane wrote:
> Simon Riggs <simon@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.
We tell people very clearly in the docs and elsewhere that nextval()
guarantees uniqueness and very specifically not ordering, so with
greatest respect, I agree with Simon on its reorderability.
> > 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.
Are you referring to the Halting Problem?
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate