From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [rfc] overhauling pgstat.stat |
Date: | 2013-09-04 18:59:17 |
Message-ID: | 20130904185917.GF5227@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2013-09-04 19:46:20 | Analysis on backend-private memory usage (and a patch) |
Previous Message | Tomas Vondra | 2013-09-04 18:58:11 | Re: [rfc] overhauling pgstat.stat |