From: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Inefficient bytea escaping? |
Date: | 2006-05-26 18:23:38 |
Message-ID: | 447747AA.5030509@pse-consulting.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
>
>>Here are the results, with the copy patch:
>
>
>>psql \copy 1.4 GB from table, binary:
>>8.0 8.1 8.2dev
>>36s 34s 36s
>
>
>>psql \copy 6.6 GB from table, std:
>>8.0 8.1 8.2dev
>>375s 362s 290s (second:283s)
>
>
> Hmph. There's something strange going on on your platform (what is it
> anyway?)
Debian 2.6.26.
> It's interesting (and surprising) that the runtime is
> actually less for psql \copy than for server COPY. This is a dual Xeon
> machine, maybe the frontend copy provides more scope to use both CPUs?
The dual CPU explanation sounds reasonable, but I found the same
tendency on a single 3GHz (HT disabled).
Strange observation using top:
user >90%, sys <10%, idle+wait 0% but only postmaster consumes cpu,
showing 35%, the rest neglectable.
>
> It would be interesting to see what's happening on your machine with
> oprofile or equivalent.
I'll investigate further, trying to find the missing CPU.
Regards,
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-05-26 18:50:05 | Re: Creating a case insensitive data type |
Previous Message | Greg Stark | 2006-05-26 18:04:51 | Re: Updatable views/with check option parsing |