From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Subject: | Re: Large writable variables |
Date: | 2018-10-15 21:02:59 |
Message-ID: | 20181015210259.3n7enpwlw3iy3apy@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2018-10-15 21:16:34 | Re: Large writable variables |
Previous Message | Tom Lane | 2018-10-15 20:54:53 | Re: Large writable variables |