Re: Inefficient bytea escaping?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Inefficient bytea escaping?
Дата
Msg-id 2467.1148684419@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Inefficient bytea escaping?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Inefficient bytea escaping?  ("Marko Kreen" <markokr@gmail.com>)
Re: Inefficient bytea escaping?  (Andreas Pflug <pgadmin@pse-consulting.de>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Updatable views/with check option parsing
Следующее
От: "Mark Woodward"
Дата:
Сообщение: Re: LIKE, leading percent, bind parameters and indexes