Horton

Re: Large writable variables

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@enterprisedb.com>
Date: 2018-10-15T21:02:59Z
Lists: pgsql-hackers 
Hi,

On 2018-10-15 16:54:53 -0400, Tom Lane wrote:
> 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.

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

Commits

  1. Apply unconstify() in more places

  2. Improve unconstify() documentation

  3. Drop const cast from dlsym() calls

  4. Const-ify a few more large static tables.

  5. Improve tzparse's handling of TZDEFRULES ("posixrules") zone data.

  6. Avoid statically allocating statement cache in ecpglib/prepare.c.

  7. Reorder FmgrBuiltin members, saving 25% in size.

  8. Add macro to cast away const without allowing changes to underlying type.

  9. Mark constantly allocated dest receiver as const.

  10. Avoid statically allocating formatting.c's format string caches.

  11. Correct constness of system attributes in heap.c & prerequisites.

  12. Avoid statically allocating gmtsub()'s timezone workspace.

  13. Correct constness of a few variables.

  14. Move the replication lag tracker into heap memory.