Re: snprintf.c hammering memset()
От | Tom Lane |
---|---|
Тема | Re: snprintf.c hammering memset() |
Дата | |
Msg-id | 5218.1538439556@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: snprintf.c hammering memset() (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: snprintf.c hammering memset()
|
Список | 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
В списке pgsql-hackers по дате отправления: