On Sat, 2006-10-21 at 19:24 -0400, Tom Lane wrote:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
> > But they can be re-created anew with the same name each time? Or I guess
> > not, but you redefine a view every 30 minutes to point to the latest
> > one?
>
> > If so, then I have a patch that will speed up COPY when in the same
> > transaction as the table that created it. I've finally fixed a bug in my
> > earlier prototypes that seems to make that work now, in all cases.
>
> Can you make the patch cover the case of
>
> begin;
> truncate foo;
> copy foo from ...
> commit;
>
> It might be infeasible to detect this case, but if it's not ...
I think it is possible to detect this case without making catalog
entries, so I'll give this a try. Methinks that the truncate *must* be
the immediately preceding command, otherwise we might have a trigger
executing to put rows back into the table before we COPY.
I should also be able to get that to work with Insert Select without
much bother too.
We might also add this capability to COPY itself by providing a WITH
TRUNCATE option, which would be even cleaner code-wise. We can add that
to pg_dump so it will work with/without --single-transaction mode. That
will change the permissions reqd slightly, but seems OK.
I'll go for all of the above changes unless there are objections.
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com