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
-
Set snprintf.c's maximum number of NL arguments to be 31.
- dee848810d8a 9.5.15 landed
- d5895717e000 9.6.11 landed
- a5b46fc66dfb 9.4.20 landed
- a051c19c3cf4 11.0 landed
- 6483381a4d0b 10.6 landed
- 625b38ea0e98 12.0 landed
- 4ed6dc7d4b33 9.3.25 landed