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

Поиск
Список
Период
Сортировка
От Zoltan Boszormenyi
Тема Re: [HACKERS] Performance testing of COPY (SELECT) TO
Дата
Msg-id 44F323EC.6000104@dunaweb.hu
обсуждение исходный текст
Ответ на Re: [HACKERS] Performance testing of COPY (SELECT) TO  (Alvaro Herrera <alvherre@commandprompt.com>)
Ответы Re: [HACKERS] Performance testing of COPY (SELECT) TO  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-patches
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.


>>> It's ugly because you are forcing the system to parse something that
>>> was already parsed.
>>>
>> Well, to be true to the word, during parsing COPY view TO
>> the parser never saw SELECT * FROM view.
>>
>
> Hmm!
>
> The COPY view stuff stopped working when I changed back the "relation"
> case.  Your patch changed it so that instead of flowing as RangeVar all
> the way to the copy.c code, the parser changed it into a "select * from
> %s" query, and then stashed the resulting Query node into the "query"
> %case.  (So what was happening was that the Relation case was never
> %used).  I reverted this.
>

Well, the VIEW case wasn't  supported before
so I took the opportunity to transform it in
analyze.c which you deleted as being ugly.

>>> 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")?


В списке pgsql-patches по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: updated patch for selecting large results sets in psql using cursors
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [HACKERS] Performance testing of COPY (SELECT) TO