Re: pg_stat_*_columns?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_stat_*_columns?
Дата
Msg-id 65642.1434838544@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_stat_*_columns?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: pg_stat_*_columns?
Re: pg_stat_*_columns?
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> One idea would be to advertise a DSM ID in the main shared memory
> segment, and have the individual backends read that value and attach
> to it.  When new stats are generated, the stats collector creates a
> new DSM (which might be bigger or smaller than the old one), writes
> the new stats in there, and then advertises the new DSM ID in the main
> shared memory segment.  Backends that still have the old segment
> attached can still use it, and it will go away automatically once they
> all drop off.

Hmmm.  This sounds attractive, but what happens if we fail to create
a new DSM when needed?

> But I'm not sure how this would work with the new per-database split
> of the stats file.  I don't think it'll work to have one DSM per
> database; we don't support enough DSMs for that.

AFAIR, that per-database split exists only to try to reduce the amount of
traffic written to disk.  We could lose it cheerfully if the communication
all happens in shared memory.
        regards, tom lane



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: The real reason why TAP testing isn't ready for prime time
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Inheritance planner CPU and memory usage change since 9.3.2