From: | Atri Sharma <atri(dot)jiit(at)gmail(dot)com> |
---|---|
To: | Satoshi Nagayasu <snaga(at)uptime(dot)jp> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [rfc] overhauling pgstat.stat |
Date: | 2013-09-04 03:52:13 |
Message-ID: | CAOeZVifbqgQFMk1iwu18DEtDSXBxP5jUEERwz2mk=qE3LZavyg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 4, 2013 at 6:40 AM, Satoshi Nagayasu <snaga(at)uptime(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-09-04 04:07:54 | Re: [rfc] overhauling pgstat.stat |
Previous Message | Bruce Momjian | 2013-09-04 02:56:20 | Re: strange IS NULL behaviour |