On Mon, Nov 27, 2017 at 1:49 AM, Kyotaro HORIGUCHI <horiguchi.kyot...@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
