Re: Make printtup a bit faster

From: Andy Fan <zhihuifan1213(at)163(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andreas Karlsson <andreas(at)proxel(dot)se>, David Rowley <dgrowleyml(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Make printtup a bit faster
Date: 2024-09-12 10:31:41
Message-ID: 87seu5duya.fsf@163.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


>> ... I'd put parts of out(print) function
>> refactor in the next 2 days. I think it deserves a double check before
>> working on *all* the out function.
>
> Well, sure. You *cannot* write a patch that breaks existing output
> functions. Not at the start, and not at the end either. You
> should focus on writing the infrastructure and, for starters,
> converting just a few output functions as a demonstration. If
> that gets accepted then you can work on converting other output
> functions a few at a time. But they'll never all be done, because
> we can't realistically force extensions to convert.
>
> There are lots of examples of similar incremental conversions in our
> project's history. I think the most recent example is the "soft error
> handling" work (d9f7f5d32, ccff2d20e, and many follow-on patches).

Thank you for this example! What I want is a smaller step than you said.
Our goal is to make out function take an extra StringInfo input to avoid
the extra palloc, memcpy, strlen. so the *final state* is:

1). implement all the out functions with (datum, StringInfo) as inputs.
2). change all the caller like printtup or any other function.
3). any extensions which doesn't in core has to change their out function
for their data type. The patch in this thread can't help in this area,
but I guess it would not be very hard for extension's author.

The current (intermediate) stage is:
- I finished parts of step (1), 17 functions in toally. and named it as
print function, the function body is exactly same as the out function in
final stage, so this part is reviewable.
- I use them in printtup user case. so it is testable (for correctness
and performance test purpose).

so I want some of you can have a double check on these function bodies, if
anything wrong, I can change it easlier (vs I made the same efforts on
all the type function). does it make sense?

Patch 0001 ~ 0003 is something related and can be reviewed or committed
seperately. and 0004 is the main part of the above.

--
Best Regards
Andy Fan

Attachment Content-Type Size
v20240912-0003-add-unlikely-hint-for-enlargeStringInfo.patch text/x-diff 1.3 KB
v20240912-0001-Refactor-float8out_internval-for-better-pe.patch text/x-diff 6.3 KB
v20240912-0002-Continue-to-remove-some-unnecesary-strlen-.patch text/x-diff 2.4 KB
v20240912-0004-Make-printtup-a-bit-faster-intermediate-st.patch text/x-diff 29.9 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2024-09-12 10:41:23 Re: Docs: Order of json aggregate functions
Previous Message jian he 2024-09-12 10:13:00 Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row