Re: shared-memory based stats collector - v70 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: shared-memory based stats collector - v70
Date
Msg-id 1736122.1658333315@sss.pgh.pa.us
Whole thread Raw
In response to Re: shared-memory based stats collector - v70  (Melanie Plageman <melanieplageman@gmail.com>)
Responses Re: shared-memory based stats collector - v70
Re: shared-memory based stats collector - v70
List pgsql-hackers
Melanie Plageman <melanieplageman@gmail.com> writes:
> On Wed, Jul 20, 2022 at 11:35 AM Greg Stark <stark@mit.edu> wrote:
>> It seems like if we really think the total number of database objects
>> is reasonably limited to scales that fit in RAM there would be a much
>> simpler database design that would just store the catalog tables in
>> simple in-memory data structures and map them all on startup without
>> doing all the work Postgres does to make relational storage scale.

> I think efforts to do such a thing have gotten caught up in solving
> issues around visibility and managing the relationship between local and
> global caches [1]. It doesn't seem like the primary technical concern
> was memory usage.

AFAIR, the previous stats collector implementation had no such provision
either: it'd just keep adding hashtable entries as it received info about
new objects.  The only thing that's changed is that now those entries are
in shared memory instead of process-local memory.  We'd be well advised to
be sure that memory can be swapped out under pressure, but otherwise I'm
not seeing that things have gotten worse.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: shared-memory based stats collector - v70
Next
From: Jeff Davis
Date:
Subject: Re: Logical insert/update/delete WAL records for custom table AMs