Re: [HACKERS] More stats about skipped vacuums

At Mon, 27 Nov 2017 10:03:25 +0900, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote in <CAB7nPqTaVWd9vAjRzMOCKHP9k6ge-0u4w_7-YHKZ+gynGN8fpg(at)mail(dot)gmail(dot)com>
> On Mon, Nov 27, 2017 at 5:19 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> >> On Sat, Nov 25, 2017 at 12:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >>> Mumble. It's a property I'm pretty hesitant to give up, especially
> >>> since the stats views have worked like that since day one. It's
> >>> inevitable that weakening that guarantee would break peoples' queries,
> >>> probably subtly.
> >
> >> You mean, queries against the stats views, or queries in general? If
> >> the latter, by what mechanism would the breakage happen?
> >
> > Queries against the stats views, of course.
>
> There has been much discussion on this thread, and the set of patches
> as presented may hurt performance for users with a large number of
> tables, so I am marking it as returned with feedback.
> --
> Michael

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.

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).

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center