Re: [rfc] overhauling pgstat.stat

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [rfc] overhauling pgstat.stat
Дата
Msg-id 20130904121317.GY2706@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [rfc] overhauling pgstat.stat  (Satoshi Nagayasu <snaga@uptime.jp>)
Ответы Re: [rfc] overhauling pgstat.stat  (Tomas Vondra <tv@fuzzy.cz>)
Список pgsql-hackers
Satoshi,

* Satoshi Nagayasu (snaga@uptime.jp) wrote:
> (2013/09/04 13:07), Alvaro Herrera wrote:
> >We already changed it:
> >
> > commit 187492b6c2e8cafc5b39063ca3b67846e8155d24
> > Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
> > Date:   Mon Feb 18 17:56:08 2013 -0300
> >
> >      Split pgstat file in smaller pieces
>
> Thanks for the comments. I forgot to mention that.
>
> Yes, we have already split single pgstat.stat file into
> several pieces.
>
> However, we still need to read/write large amount of statistics
> data when we have a large number of tables in single database
> or multiple databases being accessed. Right?

Would simply also splitting per tablespace help?

> I think the issue here is that it is necessary to write/read
> statistics data even it's not actually changed.
>
> So, I'm wondering how we can minimize read/write operations
> on these statistics data files with using heap and btree.

It does sound like an interesting idea to use heap/btree instead but I
wonder about the effort involved, particularly around coordinating
access.  We wouldn't want to end up introducing additional contention
points by doing this..
Thanks,
    Stephen

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

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: Is it necessary to rewrite table while increasing the scale of datatype numeric???
Следующее
От: Atri Sharma
Дата:
Сообщение: Re: [rfc] overhauling pgstat.stat