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 |
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 |