Re: Cleaning up and speeding up string functions

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Cleaning up and speeding up string functions
Date: 2019-06-05 20:54:24
Message-ID: 20190605205424.GA15382@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-May-26, David Rowley wrote:

> On Sun, 26 May 2019 at 04:50, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-06-05 21:11:38 Re: crash testing suggestions for 12 beta 1
Previous Message Peter Eisentraut 2019-06-05 20:31:54 Re: Why does pg_checksums -r not have a long option?