Re: snprintf.c hammering memset() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: snprintf.c hammering memset()
Date
Msg-id 6536.1538441854@sss.pgh.pa.us
Whole thread Raw
In response to Re: snprintf.c hammering memset()  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.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


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: snprintf.c hammering memset()
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Re: Improve OR conditions on joined columns (commonstar schema problem)