Hi, On 2018-10-15 16:54:53 -0400, Tom Lane wrote: > Andres Freund <and...@anarazel.de> writes: > > On 2018-10-15 16:36:26 -0400, Tom Lane wrote: > >> Andres Freund <and...@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.
I don't think it's particularly uncommon to have processes that don't use any toasted datums. I'm not sure however how to put numbers on that? After all, it'll be drastically workload dependant. > >> 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. I assume you're talking about the offset approach. Performancewise I assume that my suggestion of inlining the names into the struct would be faster. Are there many realistic cases where performance matters enough to warrant the size increase? > We'd need some tooling to generate the constants that way, though; > I can't see how to make it directly from kwlist.h. I guess we could create a struct with all the strings as members. But that seems fairly nasty. Greetings, Andres Freund
