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

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

From: Zoltan Boszormenyi <zboszor(at)dunaweb(dot)hu>
To: Alvaro Herrera <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:54:37
Message-ID: 44F31FCD.4040301@dunaweb.hu (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Alvaro Herrera írta:
> Zoltan Boszormenyi wrote:
>   
>> Alvaro Herrera írta:
>>     
>
>   
>>> 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.
>>     
>
> The difference is that we are giving a very clear distinction between a
> table and a view.  If we don't support the view in the direct COPY, but
> instead insist that it be passed via a SELECT query, then the user will
> be aware that it may be slow.
>   

It still can be documented with supporting
the COPY view TO syntax.

But COPY view (col1, col2, ...) TO may still be
useful even if the COPY (SELECT ...) (col1, col2, ...) TO
is pointless. [1]

> "relname" at this point may mean anything -- are you supporting
> sequences and toast tables as well?
>   

Well, not really. :-)

>> And remember, Bruce put the original COPY view TO
>> patch into the unapplied queue, without the SELECT
>> feature.
>>     
>
> All sort of junk enters that queue so that's not an argument.  (Not
> meant to insult Bruce -- I'm just saying that he doesn't filter stuff.
> We've had patches rejected from the queue before plenty of times.)
>   

OK. :-)

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

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


Best regards,
Zoltán Böszörményi


In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2006-08-28 16:55:28
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO
Previous:From: Hans-Juergen SchoenigDate: 2006-08-28 16:49:55
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO

pgsql-patches by date

Next:From: Alvaro HerreraDate: 2006-08-28 16:55:28
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO
Previous:From: Hans-Juergen SchoenigDate: 2006-08-28 16:49:55
Subject: Re: [HACKERS] Performance testing of COPY (SELECT) TO

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