Re: [HACKERS] More stats about skipped vacuums

At Mon, 27 Nov 2017 10:03:25 +0900, Michael Paquier <michael.paquier@gmail.com> wrote in
<CAB7nPqTaVWd9vAjRzMOCKHP9k6ge-0u4w_7-YHKZ+gynGN8fpg@mail.gmail.com>
> On Mon, Nov 27, 2017 at 5:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Robert Haas <robertmhaas@gmail.com> writes:
> >> On Sat, Nov 25, 2017 at 12:09 PM, Tom Lane <tgl@sss.pgh.pa.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