From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andy Fan <zhihuifan1213@163.com>
Cc: David Rowley <dgrowleyml@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Make printtup a bit faster
Date: Mon, 04 May 2026 00:38:38 -0400
Message-ID: <117986.1777869518@sss.pgh.pa.us> (raw)
In-Reply-To: <877bpk7dyg.fsf@163.com>
References: <87wmjzfz0h.fsf@163.com>
<CAApHDvrBNA-QRsbn-SJyRAsywjHCNenfcbi14c3O3c7=OimQ8Q@mail.gmail.com>
<87bk1aj2go.fsf@163.com>
<CAApHDvqHthJb6baDhgTE5T4RLW6nEX=r239EYmpjfg=Wq5CqQA@mail.gmail.com>
<877bpk7dyg.fsf@163.com>
Andy Fan <zhihuifan1213@163.com> writes:
> You understood me correctly and I thought we should maintain one version
> two years ago, so I tried to implement this idea today. The first issue I
> want to talk about now how to define the function protocol in SQL, take
> int4out for example:
> master: cstring int4out(integer);
> New protocol: void int4out(integer, internal). and the internal is
> StringInfo acutally.
> The direct impaction would be:
> master support:
> postgres=# select int4out(8);
> int4out
> ---------
> 8
> (1 row)
> After our change, user could not invoke any {type}out function anymore
> in SQL since it takes 'internal' as an agrument. I am not sure if people
> would write SQL like this, but it'd be good to have a talk about this.
I think you missed the point of what I said two years ago: you will
never be able to remove the existing output function API, nor the
per-datatype functions that implement that API. Even if we were
willing to convert every last one of the in-core callers and callees,
doing that would break too much non-core code. So the above example
is never going to stop working.
We can consider implementing a new datatype output API alongside the
existing one. But it'd likely not be callable from SQL, so the
question of SQL compatibility is moot.
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.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, zhihuifan1213@163.com, dgrowleyml@gmail.com
Subject: Re: Make printtup a bit faster
In-Reply-To: <117986.1777869518@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox