Re: Inefficient bytea escaping?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Inefficient bytea escaping?
Date: 2006-05-26 23:00:19
Message-ID: 2467.1148684419@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> I'm off for a little visit with oprofile...

It seems the answer is that fwrite() does have pretty significant
per-call overhead, at least on Fedora Core 4. The patch I did yesterday
still ended up making an fwrite() call every few characters when dealing
with bytea text output, because it'd effectively do two fwrite()s per
occurrence of '\' in the data being output. I've committed a further
hack that buffers a whole data row before calling fwrite(). Even though
this presumably is adding one extra level of data copying, it seems to
make things noticeably faster:

bytea=# copy t to '/home/tgl/t.out';
COPY 1024
Time: 209842.139 ms

as opposed to 268 seconds before. We were already applying the
line-at-a-time buffering strategy for frontend copies, so that
path didn't change much (it's about 226 seconds for the same case).

At this point, a copy-to-file is just marginally faster than a
frontend copy happening on the local machine; which speaks well
for the level of optimization of the Linux send/recv calls.
More importantly, I see consistent results for the text and
binary cases.

Let me know what this does on your Debian machine ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2006-05-26 23:02:31 Re: Updatable views/with check option parsing
Previous Message Peter Eisentraut 2006-05-26 22:23:48 Re: Updatable views/with check option parsing