Re: pg_stat_*_columns?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: pg_stat_*_columns?
Дата
Msg-id 20150621165205.GE9243@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: pg_stat_*_columns?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: pg_stat_*_columns?
Список pgsql-hackers
On 2015-06-21 12:40:50 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > We could also just mmap() the stats file into memory in various
> > processes. With a bit care it should be quite possible to only mmap a
> > subsets of the file at once, taking care of the address space issues.
> 
> I think we should go into this with the mindset of re-using the DSM
> infrastructure, rather than inventing a new mechanism of uncertain
> portability.

Maybe. I'm rather doubtful that it's a good idea to make a choice
that'll basically force all the stats to always be in memory though.8

mmap()ing a file is one of the mechanisms for dsm, so it'd not be
totally unproven.


In totally different crazy way we could just use the existing buffer
manager we have and simply put the stats file in
shared_buffers. Inventing a per-database relfilenode that doesn't
conflict doesn't seem impossible. With some care it shouldn't be hard to
make that stats file readable from all sessions, even if they're not
connected to the database (e.g. autovacuum launcher).



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Backpatch src/test/modules to 9.3?
Следующее
От: Andres Freund
Дата:
Сообщение: Rework the way multixact truncations work