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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers 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

In response to

Responses

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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