From: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [rfc] overhauling pgstat.stat |
Date: | 2013-09-07 23:09:40 |
Message-ID: | 522BB234.50607@fuzzy.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5.9.2013 07:29, Alvaro Herrera wrote:
> Satoshi Nagayasu wrote:
>
>> But, for now, I think we should have a real index for the
>> statistics data because we already have several index storages, and
>> it will allow us to minimize read/write operations.
>>
>> BTW, what kind of index would be preferred for this purpose? btree
>> or hash?
>
> I find it hard to get excited about using the AM interface for this
> purpose. To me it makes a lot more sense to have separate, much
> simpler code. We don't need any transactionality, user defined
> types, user defined operators, or anything like that.
+1 to these concerns
And I think using regular tables might actually cause more harm than
benefits. For example let's say we have a large database with many
objects (which is the aim of this thread) with high activity - sessions
accessing objects, i.e. updating many "rows" in the stats tables.
Now, the stats table is likely to bloat thanks of the MVCC
copy-on-update. Not a good think, and it might easily happen the price
for maintenance of the table will be much higher than what we saved.
There are probably other similar scenarios.
Tomas
From | Date | Subject | |
---|---|---|---|
Next Message | Atri Sharma | 2013-09-08 05:01:15 | Re: [rfc] overhauling pgstat.stat |
Previous Message | Tomas Vondra | 2013-09-07 22:57:34 | Re: [rfc] overhauling pgstat.stat |