From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Mateusz Guzik <mjguzik(at)gmail(dot)com> |
Subject: | Re: snprintf.c hammering memset() |
Date: | 2018-10-02 00:19:16 |
Message-ID: | 5218.1538439556@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-10-02 00:39:59 | Re: [HACKERS] Optional message to user when terminating/cancelling backend |
Previous Message | Michael Paquier | 2018-10-02 00:11:51 | Re: pgsql: Improve autovacuum logging for aggressive and anti-wraparound ru |