Re: [rfc] overhauling pgstat.stat

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: [rfc] overhauling pgstat.stat
Дата
Msg-id 20130904185917.GF5227@eldon.alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: [rfc] overhauling pgstat.stat  (Tomas Vondra <tv@fuzzy.cz>)
Ответы Re: [rfc] overhauling pgstat.stat  (Tomas Vondra <tv@fuzzy.cz>)
Re: [rfc] overhauling pgstat.stat  (Satoshi Nagayasu <snaga@uptime.jp>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: [rfc] overhauling pgstat.stat
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Analysis on backend-private memory usage (and a patch)