Re: [rfc] overhauling pgstat.stat
От | Atri Sharma |
---|---|
Тема | Re: [rfc] overhauling pgstat.stat |
Дата | |
Msg-id | CAOeZVifbqgQFMk1iwu18DEtDSXBxP5jUEERwz2mk=qE3LZavyg@mail.gmail.com обсуждение исходный текст |
Ответ на | [rfc] overhauling pgstat.stat (Satoshi Nagayasu <snaga@uptime.jp>) |
Ответы |
Re: [rfc] overhauling pgstat.stat
|
Список | pgsql-hackers |
On Wed, Sep 4, 2013 at 6:40 AM, Satoshi Nagayasu <snaga@uptime.jp> wrote: > Hi, > > I'm considering overhauling pgstat.stat, and would like to know how many > people are interested in this topic. > > 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. > > To support multi-tenancy or just a large number of tables (up to 10k > tables in single database), I think pgstat.stat needs to be overhauled. > > I think using heap and btree in pgstat.stat would be preferred to reduce > read/write and to allow updating access statistics for specific tables > in pgstat.stat file. > > Is this good for us? Hi, Nice thought. I/O reduction in pgstat can be really helpful. I am trying to think of our aim here. Would we be looking to split pgstat per table, so that the I/O write happens for only a portion of pgstat? Or reduce the I/O in general? If the later, how would using BTree help us? I would rather go for a range tree or something. But again, I may be completely wrong. Please elaborate a bit more on the solution we are trying to achieve.It seems really interesting. Regards, Atri -- Regards, Atri l'apprenant
В списке pgsql-hackers по дате отправления: