Andres Freund <andres@anarazel.de> writes:
> On 2018-10-03 12:07:32 -0400, Tom Lane wrote:
>> [ scratches head ... ] How would that work? Seems like it necessarily
>> adds a strlen() call to whatever we'd be doing otherwise. palloc isn't
>> going to be any faster just from asking it for slightly fewer bytes.
>> I think there might be something wrong with your test scenario ...
>> or there's more noise in the numbers than you thought.
> I guess the difference is that we're more likely to find reusable chunks
> in aset.c and/or need fewer OS allocations. As the memory is going to
> be touched again very shortly afterwards, the cache effects probably are
> neglegible.
> The strlen definitely shows up in profiles, it just seems to save at
> least as much as it costs.
> Doesn't strike me as THAT odd?
What it strikes me as is excessively dependent on one particular test
scenario. I don't mind optimizations that are tradeoffs between
well-understood costs, but this smells like handwaving that's going to
lose as much or more often than winning, once it hits the real world.
regards, tom lane