| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: appendBinaryStringInfo stuff |
| Date: | 2022-12-19 22:26:26 |
| Message-ID: | CAApHDvrEFqv1J14Hd41ySFxztPEoLzPQBvSPGaQaQmcXZdwW5g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 20 Dec 2022 at 09:23, Peter Eisentraut
<peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> AFAICT, the code in question is for the text output of the jsonpath
> type, which is used ... for barely anything?
I think the performance of a type's output function is quite critical.
I've seen huge performance gains in COPY TO performance from
optimising output functions in the past (see dad75eb4a and aa2387e2f).
It would be good to see some measurements to find out how much adding
the strlen calls back in would cost us. If we're unable to measure the
change, then maybe the cleanup patch would be nice. If it's going to
slow COPY TO down 10-20%, then we need to leave this or consider the
inline function mentioned by Andres or the macro trick mentioned by
me.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2022-12-19 22:42:30 | Re: appendBinaryStringInfo stuff |
| Previous Message | Andrew Dunstan | 2022-12-19 22:10:17 | Re: meson files copyright |