| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: appendBinaryStringInfo stuff |
| Date: | 2022-12-30 10:25:23 |
| Message-ID: | b12b53b3-6d46-7d32-639e-b0cc95129ce8@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 23.12.22 14:01, David Rowley wrote:
> Maybe if there's concern that inlining appendStringInfoString is going
> to bloat the binary too much, then how about we just invent an inlined
> version of it using some other name that we can use when performance
> matters? We could then safely replace the offending
> appendBinaryStringInfos from both places without any concern for
> regressing performance.
The jsonpath output routines don't appear to be written with deep
concern about performance now, so I'm not sure this is the place to
start tweaking. For the jsonb parts, there are only a handful of
strings this affects ("true", "false", "null"), so using
appendBinaryStringInfo() there a few times doesn't seem so bad. So I'm
not too worried about this altogether.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | wangw.fnst@fujitsu.com | 2022-12-30 10:25:32 | RE: Perform streaming logical transactions by background workers and parallel apply |
| Previous Message | Peter Eisentraut | 2022-12-30 10:19:32 | Re: appendBinaryStringInfo stuff |