Обсуждение: type recv/send functions

Is it just me or are the send/recv strangely asymmetric?

It seems like the recv function is designed to avoid copying so the type can
pick the data straight out of the data stream without passing through
intermediate representations.

But the send function forces the type to copy the data into a temporary bytea,
which is presumably then copied into the actual data stream. 

Wouldn't the natural thing to do be to provide the StringInfo buffer with a
cursor for the type's send function to stuff the bytea into?

-- 
greg

Greg Stark <gsstark@mit.edu> writes:
> Is it just me or are the send/recv strangely asymmetric?

Not all that much: they both return a meaningful result.  We cheated a
little bit by allowing the recv functions to modify the state of their
input argument, but they still deliver a valid result object.

> Wouldn't the natural thing to do be to provide the StringInfo buffer with a
> cursor for the type's send function to stuff the bytea into?

Then the send function would return void, which is surely not more
natural.  Also, there would be a much larger disparity between the
behaviors of the text and binary output paths.

Anyway it's about three years too late to be debating this ;-)
        regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:
Stark <gsstark@mit.edu> writes:
> > Is it just me or are the send/recv strangely asymmetric?
> 
> Not all that much: they both return a meaningful result.  We cheated a
> little bit by allowing the recv functions to modify the state of their
> input argument, but they still deliver a valid result object.

"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. I would expect the complementary
function to get a pointer to the entire message, take the part it's
responsible for and stuff it into that buffer advancing the cursor.

It stands out to me because the recv api seems like it's intentionally
designed around avoiding the extra copy. Then to see the send function not
make any effort in the same direction seems odd.


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.

> Anyway it's about three years too late to be debating this ;-)

I suppose. Though it doesn't seem like it would be impossible to allow both
the "easy" form that returns a bytea and the "high performance" zero-copy
form. If there was a similar "easy" form for recv then it would be more
feasible to implement data types without C programming too.

I guess that's nowhere until I figure out a way to profile all these send
functions separately though.


-- 
greg

Greg Stark <gsstark@mit.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