Skip site navigation (1) Skip section navigation (2)

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

From: Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>
To: Hans-Juergen Schoenig <postgres(at)cybertec(dot)at>, Zoltan Boszormenyi <zboszor(at)dunaweb(dot)hu>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO
Date: 2006-08-28 16:26:52
Message-ID: 44F3194C.2010307@cybertec.at (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Alvaro Herrera wrote:
> 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;
> ?
>
>   

i would say that "copy view to stdout" is just some syntactic sugar (to 
me at least). the important thing is that we add the flexibility of 
SELECT to it. a view is nothing else than a rule on SELECT anyway. to be 
honest i never thought about views when creating this copy idea. 
however, i think it is not bad to have it because i have seen a couple 
of times already that tables turn into views when new features are added 
to an existing data structure . if we support copy on views this means 
that exports can stay as they are even if the data structure is changed 
in that way.
however, if people think that views are not needed that way it is still 
a good solution as views are not the basic reason why this new 
functionality is a good thing to have.

    many thanks,

       hans


-- 
Cybertec Geschwinde & Schönig GmbH
Schöngrabern 134; A-2020 Hollabrunn
Tel: +43/1/205 10 35 / 340
www.postgresql.at, www.cybertec.at


In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2006-08-28 16:36:30
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO
Previous:From: Tom LaneDate: 2006-08-28 16:26:23
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2006-08-28 16:36:30
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO
Previous:From: Tom LaneDate: 2006-08-28 16:26:23
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group