Hi, On 2026-02-27 10:35:39 -0500, Tom Lane wrote: > Thomas Munro <[email protected]> writes: > > I also wondered if we might have a reasonable case for using alloca(), > > where available. It's pretty much the thing we are emulating, but > > keeps the stack nice and compact without big holes to step over for > > the following call to strcoll_l() or whatever it might be. > > +1 for investigating alloca(). The one disadvantage I can see > to making this coding pattern more common is that it'll result in > increased stack usage, which is not great now and will become > considerably less great in our hypothetical multithreaded future.
Yea, that's what I immediately was thinking about too. IIRC, on linux, the stack for the "main" thread is allocated on-demand, but the stack for threads is mapped entirely upon creation (I think because it'd be hard to ensure there's space for the stack otherwise). So there's more benefit in keeping the stack small-ish with threads than there is in a process based model. That said, I've thought about accellerating a few things with an 'on-stack-if-small-palloc-otherwise' approach as well. Particularly things like small StringInfos could really benefit from it - but it'd be a nontrivial conversion, due code calling pfree on the memory. I guess we could introduce a memory context that'd do nothing for pfree(), which could be used when using the stack version, but IDK, that seems mighty ugly. However, I'm pretty unconvinced of this argument > in the past we've forgotten to pfree() large allocations and had to fix leaks because we'll continue to rely on calling something to free anyway (due to large objects) and using a different path for smaller objects just will make it harder to find those. I wish msvc implemented something akin to gcc/clang's attribute(cleanup(cleanup_function)), but it doesn't look like it does. Obviously it would if we were to compile with C++, but I don't think anybody has appetite for the work it'd need to get there. Greetings, Andres Freund
