| 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: | Whole Thread | Raw Message | 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 |