Re: Performance testing of COPY (SELECT) TO

From: Zoltan Boszormenyi <zboszor(at)dunaweb(dot)hu>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>
Subject: Re: Performance testing of COPY (SELECT) TO
Date: 2006-08-25 17:37:34
Message-ID: 44EF355E.9010805@dunaweb.hu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Hi,

Böszörményi Zoltán írta:
>> Böszörményi Zoltán <zboszor(at)dunaweb(dot)hu> writes:
>>
>>> With PostgreSQL 8.1.4, I used this:
>>>
>>> begin;
>>> select ... into temp myquery1;
>>> copy myquery1 to stdout csv delimiter '|';
>>> rollback;
>>>
>> The performance of this would doubtless vary a lot with the temp_buffers
>> setting. Did you try different values?
>>
>
> Yes, I did, but now checked back with 8.2CVS.
> The previously quoted result was achieved with
> temp_buffers = 1000 on both 8.1.4 and 8.2CVS.
> On 8.2CVS with temp_buffers = 4096, the 10 client case kills
> the machine with swapping, but the 3 client runtime with
> COPY(SELECT) went down to 2:41. The SELECT INTO TEMP
> case went down to 3:36.
>
>
>> It'd also be interesting to time the same way (with a temp table) in
>> devel. I don't remember whether we did any performance work on the
>> COPY CSV data path in this cycle, or whether that was all present in
>> 8.1. In any case it'd be worth proving that the COPY SELECT patch isn't
>> degrading performance of the copy-a-relation case.
>>
>
> I will report back with that, say on Monday.
>

It seems my previous mail hasn't reached
the hackers list, I answer here.

In the export, there is a largish table,
that has both many columns and rows.

With COPY(SELECT) patch applied:

time psql -c "copy (select * from table) to 'file'" dbx
COPY 886046

real 0m13.253s
user 0m0.000s
sys 0m0.000s

time psql -c "copy table to 'file'" dbx
COPY 886046

real 0m13.234s
user 0m0.000s
sys 0m0.000s

time psql -c "copy table to stdout" dbx >file

real 0m15.155s
user 0m0.540s
sys 0m0.450s

time psql -c "copy (select * from table) to stdout" dbx >file

real 0m15.079s
user 0m0.540s
sys 0m0.590s

Surprisingly, without the COPY(SELECT) patch it's slower,
this is the lowest from five runs, e.g. with warm caches:

time psql -c "copy table to 'file'" dbx

real 0m20.464s
user 0m0.000s
sys 0m0.010s

time psql -c "copy table to stdout" dbx >file

real 0m25.753s
user 0m0.570s
sys 0m0.460s

With the original settings, temp_buffers = 1000 on 8.2CVS,
the export runtime with one client looks like this:
first run 1:44, second run 1:12, third run 1:04.
It seems it's a bit faster both on startup and on
subsequent runs.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2006-08-25 17:37:40 Re: Tricky bugs in concurrent index build
Previous Message Zeugswetter Andreas DCP SD 2006-08-25 17:26:59 Re: Tricky bugs in concurrent index build

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2006-08-25 17:46:11 Re: [HACKERS] psql 'none' as a HISTFILE special case
Previous Message Martin Atukunda 2006-08-25 17:20:34 Re: [HACKERS] psql 'none' as a HISTFILE special case