Re: snprintf.c hammering memset()

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>, Pg Hackers <pgsql-hackers@postgresql.org>, Mateusz Guzik <mjguzik@gmail.com>
Date: 2018-10-02T00:19:16Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2018-10-01 19:52:40 -0400, Tom Lane wrote:
>> Ouch indeed.  Quite aside from cycles wasted, that's way more stack than
>> we want this to consume.  I'm good with forcing this to 16 or so ...
>> any objections?

> Especially after your performance patch, shouldn't we actually be able
> to get rid of that memset entirely?

That patch takes the memset out of the main line, but it'd still be
a performance problem for formats using argument reordering; and the
stack-space concern would remain the same.

> And if not, shouldn't we be able to reduce the per-element size of
> argtypes considerably, by using a uint8 as the base, rather than 4 byte
> per element?

argtypes is only a small part of the stack-space issue, there's also
argvalues which is (at least) twice as big.  I don't think second-guessing
the compiler about the most efficient representation for an enum is
going to buy us much here.

			regards, tom lane


Commits

  1. Set snprintf.c's maximum number of NL arguments to be 31.