Re: [HACKERS] Performance testing of COPY (SELECT) TO

Hans-Juergen Schoenig wrote:
>
> >Remember that we were talking about supporting views, not tables. And
> >if a view uses a slow query then you are in immediate danger of having a
> >slow COPY. This may not be a problem but it needs to be discussed and
> >an agreement must be reached before introducing such a change (and not
> >during feature freeze).
>
> this will definitely be the case - however, this is not what it was made
> for. it has not been made to be fast but it has been made to fulfill
> some other task. the reason why this has been implemented is: consider a
> large scale database containing hundreds of gigs of data. in our special
> case we have to export in a flexible way. the data which has to be
> exported comes from multiple tables (between 3 and 7 depending on the
> data we are looking at in this project. the export has to be performed
> in a flexible way and it needs certain parameters. defining tmp tables
> and store the data in there is simply not "nice" at all. in most cases
> exports want to transform data on the fly - speed is not as important as
> flexibility here.

My question is, if we allow this:

copy (select * from view) to stdout;

(or to a file, whatever), is it enough for you? Or would you insist on
also having

copy view to stdout;
?

We can, and the posted patch does, support the first form, but not the
second. In fact I deliberately removed support for the second form for
Zoltán's patch because it uglifies the surrounding code.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.