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

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

From: Zoltan Boszormenyi <zboszor(at)dunaweb(dot)hu>
To: alvherre(at)commandprompt(dot)com, 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:16:19
Message-ID: 44F316D3.2080801@dunaweb.hu (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Alvaro Herrera írta:
> Zoltan Boszormenyi wrote:
>   
>> Andrew Dunstan írta:
>>     
>>> Alvaro Herrera wrote:
>>>       
>>>> Böszörményi Zoltán wrote:
>>>>
>>>>         
>>>>> what's the problem with COPY view TO, other than you don't like it? :-)
>>>>>           
>>>> The problem is that it required a ugly piece of code.  Not supporting it
>>>> means we can keep the code nice.  The previous discussion led to this
>>>> conclusion anyway so I don't know why we are debating it again.
>>>>         
>>> What is so ugly about it? I haven't looked at the code, but I am 
>>> curious to know.
>>>       
>
> It used a "SELECT * FROM %s" string that was passed back to the parser.
>
>   
>>> I also don't recall the consensus being quite so clear cut. I guess 
>>> there is a case for saying that if it's not allowed then you know that 
>>> "COPY relname TO" is going to be fast. But, code aesthetics aside, the 
>>> reasons for disallowing it seem a bit thin, to me.
>>>       
>> I would say the timing difference between
>> "COPY table TO" and "COPY (SELECT * FROM table) TO"
>> was  noise, so it's not even faster.
>>     
>
> 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).
>   

COPY relname TO meant tables _and_ views to me.
My previous tsting showed no difference between
COPY table TO and COPY (SELECT * FROM table) TO.
Similarly a slow query defined in the view should show
no difference between COPY view TO and
COPY (SELECT * FROM view) TO.

And remember, Bruce put the original COPY view TO
patch into the unapplied queue, without the SELECT
feature.

Rewriting COPY view TO internally to
COPY (SELECT * FROM view) TO is very
straightforward, even if you think it's ugly.
BTW, why is it ugly if I call raw_parser()
from under src/backend/parser/*.c ?
It is on a query distinct to the query the parser
is currently running. Or is it the recursion
that bothers you? It's not a possible infinite
recursion.

>> And an updatable VIEW *may* allow COPY view FROM...
>>     
>
> May I remind you that we've been in feature freeze for four weeks
> already?  Now it's *not* the time to be drooling over cool features that
> would be nice to have

Noted. However, as the COPY view TO is
a straight internal rewrite, a COPY view FROM
could also be. Even if it's a long term development.
I wasn't proposing delaying beta.

Best regards,
Zoltán Böszörményi


In response to

Responses

pgsql-hackers by date

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

pgsql-patches by date

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

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