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 44F316D3.2080801@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
List pgsql-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


pgsql-patches by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO