Hi,
On 2026-05-04 00:38:38 -0400, Tom Lane wrote:
> My own guess is that even if we built a new API, only a fairly small
> number of datatypes would find it worth the trouble to support.
> The potential win seems clear for, say, textout: there's really no
> computation to do, only data copying, so halving the amount of
> copying is attractive. But I bet you won't measure much percentage
> improvement for numeric_out or point_out.
>
> This line of thought suggests that maybe some special-purpose hack
> would be a better answer than defining a new datatype API. It's hard
> to tell without some concrete performance numbers, which are sadly
> lacking in this thread.
FWIW, I've experimented fixing this overhead before, and what I did was to
pass an optional context via the fcinfo, and output / send functions could use
memory allocated via that optional context object, rather than doing it
allocating in CurrentMemoryContext. For the send functions that looks
reasonably clean, given that it already deals with a stringinfo. For out
functions it's a bit uglier, but still somewhat acceptable.
For e.g. bytea, integers, etc this is relatively easy. Where it gets harder
is stuff like textsend(), where the encoding conversion infrastructure
basically preallocates.
It might make sense to start work on this by having a version of
pg_server_to_client() that doesn't pessimistically copy the data, but instead
have it build the converted output directly in the StringInfo. Because that
would be an independent benefit (for printtup()->pg_sendcountedtext()) and a
required building block for the better output functions.
Greetings,
Andres Freund
