Re: Inefficient bytea escaping? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Inefficient bytea escaping?
Date
Msg-id 2467.1148684419@sss.pgh.pa.us
Whole thread Raw
In response to Re: Inefficient bytea escaping?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Inefficient bytea escaping?
Re: Inefficient bytea escaping?
List 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


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Updatable views/with check option parsing
Next
From: "Mark Woodward"
Date:
Subject: Re: LIKE, leading percent, bind parameters and indexes