Re: [rfc] overhauling pgstat.stat

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 20:46:55
Message-ID: 52279C3F.4090704@fuzzy.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4.9.2013 20:59, Alvaro Herrera wrote:
> Tomas Vondra wrote:
>
>> My idea was to keep the per-database stats, but allow some sort of
>> "random" access - updating / deleting the records in place, adding
>> records etc. The simplest way I could think of was adding a simple
>> "index" - a mapping of OID to position in the stat file.
>>
>> I.e. a simple array of (oid, offset) pairs, stored in oid.stat.index or
>> something like that. This would make it quite simple to access existing
>> record
>>
>> 1: get position from the index
>> 2: read sizeof(Entry) from the file
>> 3: if it's update, just overwrite the bytes, for delete set isdeleted
>> flag (needs to be added to all entries)
>>
>> or reading all the records (just read the whole file as today).
>
> Sounds reasonable. However, I think the index should be a real index,
> i.e. have a tree structure that can be walked down, not just a plain
> array. If you have a 400 MB stat file, then you must have about 4
> million tables, and you will not want to scan such a large array every
> time you want to find an entry.

I was thinking about a sorted array, so a bisection would be a simple
and fast way to search. New items could be added to another small
unsorted array (say, 1000 elements) and this would be extended and
resorted only when this small one gets full.

Tomas

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-09-04 20:56:49 Re: Analysis on backend-private memory usage (and a patch)
Previous Message Gavin Flower 2013-09-04 20:42:35 Re: INSERT...ON DUPLICATE KEY IGNORE