From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Thomas Munro <thomas.munro@enterprisedb.com>
Subject: Re: Large writable variables
Date: Mon, 15 Oct 2018 16:36:26 -0400
Message-ID: <18430.1539635786@sss.pgh.pa.us> (raw)
In-Reply-To: <20181015200754.7y7zfuzsoux2c4ya@alap3.anarazel.de>
References: <20181015200754.7y7zfuzsoux2c4ya@alap3.anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> So we have 500kb of not-initialized memory mapped into every
> process. That's, uh, not nothing.
Bleah.
> 0000000008585088 0000000000131104 b hist_entries
> 0000000008716192 0000000000016384 b hist_start
I'm unsure what fraction of processes would have use for these.
> 0000000008435040 0000000000085280 b DCHCache
> 0000000008391168 0000000000043840 b NUMCache
We could surely allocate these on first use.
> 0000000008560224 0000000000023440 b tzdefrules_s
> 0000000008536704 0000000000023440 b gmtmem.7009
I think that tzdefrules_s is not used in common cases (though I could be
wrong about that), so we could win by alloc-on-first-use. The same might
be true for gmtmem, but there's a sticking point: there is no provision
for failure there, so I'm unsure how we avoid crashing on OOM.
> 0000000008238336 0000000000008192 b PqRecvBuffer
> 0000000008734208 0000000000005136 B BackendWritebackContext
> 0000000008386368 0000000000003200 b held_lwlocks
These are below my personal threshold of pain.
> fmgr_builtins isn't readonly even though declared a const - I assume
> because it's full of addresses that will be mapped differently from
> execution to execution.
Check.
> I'm unclear as to why ScanKeywords, DCH_keywords aren't in a readonly
> section.
I think it's the same problem: pointers can't be truly const because
they have to be changed if one relocates the executable.
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.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, andres@anarazel.de, thomas.munro@enterprisedb.com
Subject: Re: Large writable variables
In-Reply-To: <18430.1539635786@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox