Re: [HACKERS] More stats about skipped vacuums
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] More stats about skipped vacuums |
Дата | |
Msg-id | CA+Tgmob2tuqvEZfHV2kLC-xobsZxDWGdc1WmjLg5+iOPLa0NHg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] More stats about skipped vacuums (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: [HACKERS] More stats about skipped vacuums
|
Список | pgsql-hackers |
On Mon, Nov 27, 2017 at 1:49 AM, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote: > Hmmm. Okay, we must make stats collector more effeicient if we > want to have additional counters with smaller significance in the > table stats. Currently sizeof(PgStat_StatTabEntry) is 168 > bytes. The whole of the patchset increases it to 232 bytes. Thus > the size of a stat file for a database with 10000 tables > increases from about 1.7MB to 2.4MB. DSM and shared dynahash is > not dynamically expandable so placing stats on shared hash > doesn't seem effective. Stats as a regular table could work but > it seems too-much. dshash, which is already committed, is both DSM-based and dynamically expandable. > Is it acceptable that adding a new section containing this new > counters, which is just loaded as a byte sequence and parsing > (and filling the corresponding hash) is postponed until a counter > in the section is really requested? The new counters need to be > shown in a separate stats view (maybe named pg_stat_vacuum). Still makes the stats file bigger. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: