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: 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:06:18
Message-ID: 44F3147A.2010406@cybertec.at (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
> 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.

so in my view the speed argument does not matter. if somebody passes a 
stupid query to copy he will get stupid runtimes - just like on ordinary 
sql. however, we can use COPY's capabilities to format / escape data to 
make exports more flexible. so basically it is a win.

    best regards,

       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

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2006-08-28 16:13:15
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO
Previous:From: Alvaro HerreraDate: 2006-08-28 15:59:18
Subject: Re: [PATCHES] Another VPATH patch for ecpg

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2006-08-28 16:13:15
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO
Previous:From: Alvaro HerreraDate: 2006-08-28 15:59:18
Subject: Re: [PATCHES] Another VPATH patch for ecpg

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