Re: COPY and Volatile default expressions - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: COPY and Volatile default expressions
Date
Msg-id 516C1F8C.2000903@vmware.com
Whole thread Raw
In response to COPY and Volatile default expressions  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: COPY and Volatile default expressions
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: hubert depesz lubaczewski
Date:
Subject: Re: Why are JSON extraction functions STABLE and not IMMUTABLE?
Next
From: Tom Lane
Date:
Subject: Re: Why are JSON extraction functions STABLE and not IMMUTABLE?