From: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [rfc] overhauling pgstat.stat |
Date: | 2013-09-04 18:58:11 |
Message-ID: | 522782C3.1010409@fuzzy.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 4.9.2013 14:13, Stephen Frost wrote:
> * Satoshi Nagayasu (snaga(at)uptime(dot)jp) wrote:
>
>> 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 don't think that's a good solution. Forcing the users to use
tablespaces just to minimize the stats overhead is not that far from
forcing them to use multiple databases.
Tablespaces have disadvantages too, so I'd suggest to look for a
solution metting the "just works" criterion.
>> 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..
Yes, this is definitely an important thing to keep in mind. Maintaining
the "index" (no matter what kind of index will be used) will cause some
contention, but I believe it will be manageable with a bit of effort.
Tomas
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2013-09-04 18:59:17 | Re: [rfc] overhauling pgstat.stat |
Previous Message | Pavel Stehule | 2013-09-04 18:50:45 | Re: [rfc] overhauling pgstat.stat |