Re: generic copy options - Mailing list pgsql-hackers

From Dan Colish
Subject Re: generic copy options
Date
Msg-id 20090918003143.GG13715@funkstrom.spiretech.com
Whole thread Raw
In response to Re: generic copy options  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: generic copy options
List pgsql-hackers
On Thu, Sep 17, 2009 at 07:45:45PM -0400, Andrew Dunstan wrote:
>
>
> Dan Colish wrote:
>>     CREATE TABLE
>>     INSERT 0 100000
>>     Timing is on.
>>     COPY 100000
>>     Time: 83.273 ms
>>     BEGIN
>>     Time: 0.412 ms
>>     TRUNCATE TABLE
>>     Time: 0.357 ms
>>     COPY 100000
>>     Time: 140.911 ms
>>     COMMIT
>>     Time: 4.909 ms
>>
>>
>>   
>
> Anything that doesn't have times that are orders of magnitude greater  
> than this is pretty much useless as a measurement of COPY performance,  
> IMNSHO.
>
> In this particular test, to check for paring times, I'd be inclined to  
> do copy repeatedly (i.e. probably quite a few thousand times) from an  
> empty file to test the speed. Something like:
>
>    select current_timestamp;
>    begin;
>    truncate;
>    copy;copy;copy; ...
>    commit;
>    select current_timestamp;
>
>
> (tests like this are really a good case for DO ' something'; - we could  
> put a loop in the DO.)
>
> cheers
>
> andrew
>

Ok, so I ran something like you suggested and did a simple copy from an
empty file to just test the parsing. I have the COPY statement run 3733
times in the transaction block and did the select timestamps, but I
still only was a few milliseconds difference between the two versions.
Maybe a more complex copy statment could be a better test of the parser,
but I do not see a significant difference of parsing speed here.

--
--Dan


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: generic copy options
Next
From: Robert Haas
Date:
Subject: Re: generic copy options