Re: [HACKERS] Performance testing of COPY (SELECT) TO - Mailing list pgsql-patches

From Zoltan Boszormenyi
Subject Re: [HACKERS] Performance testing of COPY (SELECT) TO
Date
Msg-id 44F3294F.5080300@dunaweb.hu
Whole thread Raw
In response to Re: [HACKERS] Performance testing of COPY (SELECT) TO  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: [HACKERS] Performance testing of COPY (SELECT) TO
Re: [HACKERS] Performance testing of COPY (SELECT) TO
Re: [HACKERS] Performance testing of COPY (SELECT) TO
List pgsql-patches
Alvaro Herrera írta:
> 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.
>

Yes, it was even documented. I thought about having
queries stored statically somewhere (not in views) and
being able to use only part of the result.

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

No, but it may be confusing seeing
COPY (SELECT ) (col1, col2, ...) TO
instead of COPY (SELECT col1, col2, ...) TO.
With the COPY VIEW (col1, col2, ...) TO syntax
it may be cleaner from the user's point of view.
Together with the changing schemas argument
it gets more and more tempting.

>>>>> 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.
>

OK, I will put it back as it was in v8
keeping all your other cleanup and
let Bruce and Tom decide.

(BTW, is there anyone as high-ranking as them,
or the "committee" is a duumvirate? :-) )


pgsql-patches by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: updated patch for selecting large results sets in psql using cursors
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO