On Thu, 6 Jun 2019 at 08:54, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
> On 2019-May-26, David Rowley wrote:
>
> > On Sun, 26 May 2019 at 04:50, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > > Here the cost is code space rather than programmer-visible complexity,
> > > but I still doubt that it's worth it.
> >
> > I see on today's master the postgres binary did grow from 8633960
> > bytes to 8642504 on my machine using GCC 8.3, so you might be right.
> > pg_receivewal grew from 96376 to 96424 bytes.
>
> I suppose one place that could be affected visibly is JSON object
> construction (json.c, jsonfuncs.c) that could potentially deal with
> millions of stringinfo manipulations, but most of those calls don't
> actually use appendStringInfoString with constant values, so it's
> probably not worth bothering with.
We could probably get the best of both worlds by using a macro and
__builtin_constant_p() to detect if the string is a const, but I won't
be pushing for that unless I find something to make it worthwhile.
For patch 0004, I think it's likely worth revising so instead of
adding a new function, make use of appendBinaryStringInfo() and pass
in the known length. Likely mostly for the xml.c calls.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services