Re: Large writable variables

Hi,

On 2018-10-15 16:54:53 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2018-10-15 16:36:26 -0400, Tom Lane wrote:
> >> Andres Freund <andres(at)anarazel(dot)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