From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: shared memory based stat collector (was: Sharing record typmods between backends)
Date: Sun, 13 Aug 2017 21:59:30 -0400
Message-ID: <32138.1502675970@sss.pgh.pa.us> (raw)
In-Reply-To: <20170814005656.d5tvz464qkmz66tq@alap3.anarazel.de>
References: <20170814005656.d5tvz464qkmz66tq@alap3.anarazel.de>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Andres Freund <andres@anarazel.de> writes:
> You both are obviously right. Another point of potential concern could
> be that we'd pretyt much fully rely on dsm/dht's being available, for
> the server to function correctly. Are we ok with that? Right now
> postgres still works perfectly well, leaving parallelism aside, with
> dynamic_shared_memory_type = none.
In principle we could keep the existing mechanism as a fallback.
Whether that's worth the trouble is debatable. The current code
in initdb believes that every platform has some type of DSM support
(see choose_dsm_implementation). Nobody's complained about that,
and it certainly works on every buildfarm animal. So for all we know,
dynamic_shared_memory_type = none is broken already.
> I think there's two other relevant points here:
> a) It'd be quite useful to avoid needing a whole cluster's stats in
> memory. Even if $subject would save memory, I'm hesitant committing
> to something requiring all stats to be in memory forever. As a first
> step it seems reasonable to e.g. not require state for all databases
> to be in memory. The first time per-database stats are required, it
> could be "paged in". Could even be more aggressive and do that on a
> per-table level and just have smaller placeholder entries for
> non-accessed tables, but that seems more work.
Huh? As long as we don't lock the shared memory into RAM, which on most
platforms we couldn't do without being root anyway, ISTM the kernel should
do just fine at paging out little-used areas of the stats. Let's not
reinvent that wheel until there's demonstrable proof of need.
> b) I think our tendency to dump all stats whenever we crash isn't really
> tenable, given how autovacuum etc are tied to them.
Eh, maybe. I don't think crashes are really so common on production
systems. As developers we have an inflated view of their frequency ;-)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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, robertmhaas@gmail.com, thomas.munro@enterprisedb.com, dilipbalaut@gmail.com
Subject: Re: shared memory based stat collector (was: Sharing record typmods between backends)
In-Reply-To: <32138.1502675970@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