Re: [rfc] overhauling pgstat.stat

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: [rfc] overhauling pgstat.stat
Дата
Msg-id 20130904040754.GD5227@eldon.alvh.no-ip.org
обсуждение исходный текст
Ответ на [rfc] overhauling pgstat.stat  (Satoshi Nagayasu <snaga@uptime.jp>)
Ответы Re: [rfc] overhauling pgstat.stat  (Satoshi Nagayasu <snaga@uptime.jp>)
Список pgsql-hackers
Satoshi Nagayasu wrote:

> As you may know, this file could be handreds of MB in size, because
> pgstat.stat holds all access statistics in each database, and it needs
> to read/write an entire pgstat.stat frequently.
> 
> As a result, pgstat.stat often generates massive I/O operation,
> particularly when having a large number of tables in the database.

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      We now write one file per database and one global file, instead of   having
thewhole thing in a single huge file.  This reduces the I/O that   must be done when partial data is required -- which
isall the time,   because each process only needs information on its own database anyway.   Also, the autovacuum
launcherdoes not need data about tables and   functions in each database; having the global stats for all DBs is
enough.     Catalog version bumped because we have a new subdir under PGDATA.      Author: Tomas Vondra.  Some rework
byÁlvaro   Testing by Jeff Janes   Other discussion by Heikki Linnakangas, Tom Lane.
 


I don't oppose further tweaking, of course, but I wonder if you are
considering these changes.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



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

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