Andres Freund <andres@anarazel.de> writes:
> On 2018-10-15 16:36:26 -0400, Tom Lane wrote:
>> Andres Freund <andres@anarazel.de> writes:
>>> 0000000008585088 0000000000131104 b hist_entries
>>> 0000000008716192 0000000000016384 b hist_start
>> I'm unsure what fraction of processes would have use for these.
> Yea, I'm not sure either. Although I suspect that given the cost of
> compression having an "allocate on first use" check should be quite
> doable.
I don't think the extra check would be a problem, but if we end up
needing the space in most processes, we're not really buying anything.
It'd need some investigation.
>> We could possibly fix these by changing the data structure so that
>> what's in a ScanKeywords entry is an offset into some giant string
>> constant somewhere. No idea how that would affect performance, but
>> I do notice that we could reduce the sizeof(ScanKeyword), which can't
>> hurt.
> Yea, that might even help performancewise. Alternatively we could change
> ScanKeyword to store the keyword name inline, but that'd be a measurable
> size increase...
Yeah. It also seems like doing it this way would improve locality of
access: the pieces of the giant string would presumably be in the same
order as the ScanKeywords entries, whereas with the current setup,
who knows where the compiler has put 'em or in what order.
We'd need some tooling to generate the constants that way, though;
I can't see how to make it directly from kwlist.h.
regards, tom lane
