| From: | Andy Fan <zhihuifan1213(at)163(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | Re: Make printtup a bit faster |
| Date: | 2026-05-03 14:41:27 |
| Message-ID: | 877bpk7dyg.fsf@163.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi David,
> On Fri, 30 Aug 2024 at 12:10, Andy Fan <zhihuifan1213(at)163(dot)com> wrote:
>> What would be the extra benefit we redesign all the out functions?
>
> If I've understood your proposal correctly, it sounds like you want to
> invent a new "print" output function for each type to output the Datum
> onto a StringInfo, if that's the case, what would be the point of
> having both versions?
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.
--
Best Regards
Andy Fan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Paul A Jungwirth | 2026-05-03 15:57:46 | Re: UPDATE/DELETE FOR PORTION OF fire FOR EACH STATEMENT more than once |
| Previous Message | Ilia Evdokimov | 2026-05-03 14:16:24 | Re: [PATCH] ANALYZE: hash-accelerate MCV tracking for equality-only types |