On Thu, 6 Jun 2019 at 08:54, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > On 2019-May-26, David Rowley wrote: > > > On Sun, 26 May 2019 at 04:50, Tom Lane <t...@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