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

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

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Zoltan Boszormenyi <zboszor(at)dunaweb(dot)hu>
Cc: 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 17:24:05
Message-ID: 20060828172405.GU27526@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Zoltan Boszormenyi wrote:
> Alvaro Herrera írta:
> >Zoltan Boszormenyi wrote:
> >  
> >>Alvaro Herrera írta:
> >  
> >>But COPY view (col1, col2, ...) TO may still be
> >>useful even if the COPY (SELECT ...) (col1, col2, ...) TO
> >>is pointless. [1]
> >>    
> >
> >Hum, I don't understand what you're saying here -- are you saying that
> >you can't do something with the first form, that you cannot do with the
> >second?
> 
> Say you have a large often used query.
> Would you like to retype it every time
> or just create a view? Later you may want to
> export only a subset of the fields...
> 
> My v8 had the syntax support for
> 
> COPY (SELECT ...) (col1, col2, ...) TO
> and it was actually working. In your v9
> you rewrote the syntax parsing so that
> feature was lost in translation.

Interesting.  I didn't realize this was possible -- obviously I didn't
test it (did you have a test for it in the regression tests?  I may have
missed it).  In fact, I deliberately removed the column list from the
grammar, because it can certainly be controlled inside the SELECT, so I
thought there was no reason the support controlling it in the COPY
column list.

I don't think it's difficult to put it back.  But this has nothing to do
with COPY view, does it?

> >>>On the other hand I don't see why you are arguing in favor of a useless
> >>>feature whose coding is dubious; you can have _the same thing_ with nice
> >>>code and no discussion.
> >>>      
> >>Because of [1] and because Mr. Schoenig's arguments
> >>about changing schemas.
> >
> >Yeah, that argument makes sense to me as well.
> 
> So, may I put it back? :-)
> Also, can you suggest anything cleaner than
> calling raw_parser("SELECT * FROM view")?

I think at this point is someone else's judgement whether you can put it
back or not.  Tom already said that he doesn't object to the feature per
se; no one else seems opposed to the feature per se, in fact.

Now, I don't really see _how_ to do it in nice code, so no, I don't have
any suggestion for you.  You may want to give the pumpkin to Tom so that
he gives the patch the finishing touches (hopefully making it support
the "COPY view" feature as well).

If it were up to me, I'd just commit it as is (feature-wise -- more
thorough review is still needed) and revisit the COPY view stuff in 8.3
if there is demand.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2006-08-28 17:26:02
Subject: Re: updated patch for selecting large results sets in psql using cursors
Previous:From: Zoltan BoszormenyiDate: 2006-08-28 17:12:12
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO

pgsql-patches by date

Next:From: Peter EisentrautDate: 2006-08-28 17:26:02
Subject: Re: updated patch for selecting large results sets in psql using cursors
Previous:From: Zoltan BoszormenyiDate: 2006-08-28 17:12:12
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO

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