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
