Re: shared-memory based stats collector - v70

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: shared-memory based stats collector - v70
Дата
Msg-id 1736122.1658333315@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: shared-memory based stats collector - v70  (Melanie Plageman <melanieplageman@gmail.com>)
Ответы Re: shared-memory based stats collector - v70  (Andres Freund <andres@anarazel.de>)
Re: shared-memory based stats collector - v70  (Greg Stark <stark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: shared-memory based stats collector - v70
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Logical insert/update/delete WAL records for custom table AMs