From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: Don't deform column-by-column in composite_to_json |
Date: | 2019-02-06 16:31:07 |
Message-ID: | 28893.1549470667@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 2019-02-05 22:53:37 -0300, Alvaro Herrera wrote:
>> Isn't this putting much more than needed in the stack? Seems like we
>> could just allocate tupdesc->natts members dynamically. Not sure if we
>> care: it's about 12 kB; maybe considering palloc overhead, using the
>> stack is better.
> "it" being allocating values/nulls on the stack? I think there's plenty
> of places that do that. But it's also worth considering whether the
> relevant piece of code calls more deeply into other code, in which case
> the stack usage might be more problematic.
I think it's OK as long as there's a stack depth check here or somewhere
real close by.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-02-06 16:34:10 | Re: bug tracking system |
Previous Message | Alvaro Herrera | 2019-02-06 16:30:50 | Re: Too rigorous assert in reorderbuffer.c |