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:57:34 |
Message-ID: | 6536.1538441854@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 20:19:16 -0400, Tom Lane wrote:
>> 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.
> What I mean is that it shouldn't be that hard to only zero out the
> portions of the array that are actually used, and thus could refrain
> from introducing the limit.
Well, we use the zeroing exactly to detect which entries have been used.
Probably there's another way, but I doubt it'd be faster.
In any case, the stack-space-consumption problem remains, and IMO that
is a *far* greater concern than the cycles. Keep in mind that we'll be
calling this code when we have already hit our stack space consumption
limit. I'm a bit surprised that we've not seen any buildfarm members
fall over in the error recursion test. We have not designed the system
on the assumption that ereport() could eat half a meg of stack.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-10-02 01:11:18 | Re: [HACKERS] Re: Improve OR conditions on joined columns (common star schema problem) |
Previous Message | Andres Freund | 2018-10-02 00:53:19 | Re: snprintf.c hammering memset() |