Greg Stark <gsstark(at)mit(dot)edu> writes:
> "both return something" seems like an odd axis to measure.
> In one case it's given pointer to the entire message, picks out the piece it's
> interested in and advances the cursor.
This is just a trivial optimization compared to being handed a bytea
input, which would be the "clean" version. (I had originally thought
we could fake a bytea input without any copying, much as is done in the
text input path, but that fails on machines that are persnickety about
alignment: the "bytea" length word might not be word-aligned depending
on message contents.)
> What I'm pondering here is that the extra copy to construct the bytea for
> every single data type being output seems like it would be a pretty big
> contribution to the complaint that postgres takes too much cpu in cases that
> should be entirely i/o bound.
Since approximately zero percent of the people making that complaint are
using binary output, I don't think it matters.
regards, tom lane
In response to
pgsql-hackers by date
|Next:||From: Marko Kreen||Date: 2006-05-30 07:44:31|
|Subject: Re: Inefficient bytea escaping?|
|Previous:||From: Greg Stark||Date: 2006-05-30 03:33:17|
|Subject: Re: type recv/send functions|