From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: hyrax vs. RelationBuildPartitionDesc
Date: Wed, 13 Mar 2019 17:10:55 -0400
Message-ID: <16519.1552511455@sss.pgh.pa.us> (raw)
In-Reply-To: <20190313205656.6eqpqua5vn4nf34d@alap3.anarazel.de>
References: <7448.1552497345@sss.pgh.pa.us>
<7961.1552498252@sss.pgh.pa.us>
<CA+TgmoaZ021fRZawzU_gozwgHMo-tXJc12uf3MJoA6k=HZsLJA@mail.gmail.com>
<10788.1552501588@sss.pgh.pa.us>
<CA+TgmoYd3vqd26RiT4sp7Mez3oQf-AxAzdBpEeTyCNF-7OchhA@mail.gmail.com>
<12316.1552504492@sss.pgh.pa.us>
<CA+TgmoacZD_WWWQ+_Fx93rGeSri=rzXO1SQ7XbW1BSns8DCh5Q@mail.gmail.com>
<14279.1552508314@sss.pgh.pa.us>
<CA+TgmoaYQoM4tNFU8Ni61hMxXmHbfrtuyGBK_e_EAA8mBtxLwA@mail.gmail.com>
<CA+TgmoZVzrnX+tCQX9O-rPhddivvJUsAJ0P2H7GuPzc3DEbBwQ@mail.gmail.com>
<20190313205656.6eqpqua5vn4nf34d@alap3.anarazel.de>
Andres Freund <andres@anarazel.de> writes:
> On 2019-03-13 16:50:53 -0400, Robert Haas wrote:
>> On Wed, Mar 13, 2019 at 4:38 PM Robert Haas <robertmhaas@gmail.com> wrote:
>>> On Wed, Mar 13, 2019 at 4:18 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>>> Off topic for the moment, since this clearly wouldn't be back-patch
>>>> material, but I'm starting to wonder if we should just have a context
>>>> for each relcache entry and get rid of most or all of the retail
>>>> cleanup logic in RelationDestroyRelation ...
>> It just occurred to me that one advantage of this would be that you
>> could see how much memory was being used by each relcache entry using
>> MemoryContextStats(), which seems super-appealing.
> But it might also make it frustrating to look at memory context dumps -
> we'd suddenly have many many more memory context lines we'd displayed,
> right? Wouldn't that often make the dump extremely long?
There's already a mechanism in there to suppress child contexts after
100 or so, which would almost inevitably kick in on the relcache if we
did this. So I don't believe we'd have a problem with the context dumps
getting too long --- more likely, the complaints would be the reverse.
My gut feeling is that right now relcache entries tend to be mas-o-menos
the same size, except for stuff that is *already* in sub-contexts, like
index and partition descriptors. So I'm not that excited about this
adding useful info to context dumps. I was just looking at it as a way
to make relcache entry cleanup simpler and less leak-prone.
Having said that, I do agree that CacheMemoryContext is too much of an
undifferentiated blob right now, and splitting it up seems like it'd be
good for accountability. I'd definitely be +1 for a catcache vs. relcache
vs. other caches split. You could imagine per-catcache contexts, too.
The main limiting factor here is that the per-context overhead could get
excessive.
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, robertmhaas@gmail.com, alvherre@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
Subject: Re: hyrax vs. RelationBuildPartitionDesc
In-Reply-To: <16519.1552511455@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