From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael.paquier@gmail.com>
cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>,
        Sawada Masahiko <sawada.mshk@gmail.com>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
        Robert Haas <robertmhaas@gmail.com>
Subject: Re: [HACKERS] More stats about skipped vacuums
In-reply-to: 
 <CAB7nPqTQZyHXETX0sU-10XMRy3YS6QHF1iLBxPgPBKxAkXuMJw@mail.gmail.com>
References: 
 <CAB7nPqQm_WCKuUf5RD0CzeMuMO907ZPKP7mBh-3t2zSJ9jn+PA@mail.gmail.com>
 <20171116.193402.26276109.horiguchi.kyotaro@lab.ntt.co.jp>
 <CAB7nPqQV1Emkj=5VFzui250T6v+xcpRQ2RfHu_oQMbdXnZw3mA@mail.gmail.com>
 <20171121.160957.124460918.horiguchi.kyotaro@lab.ntt.co.jp>
 <CA+TgmoZtsZLMd8ku2fwjf=B9Txz8CKCLNkbmz1yzMy7CMU_eEg@mail.gmail.com>
 <CAB7nPqTQZyHXETX0sU-10XMRy3YS6QHF1iLBxPgPBKxAkXuMJw@mail.gmail.com>
Comments: In-reply-to Michael Paquier <michael.paquier@gmail.com>
	message dated "Sat, 25 Nov 2017 19:52:42 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1322.1511624064.1@sss.pgh.pa.us>
Date: Sat, 25 Nov 2017 10:34:24 -0500
Message-ID: <1323.1511624064@sss.pgh.pa.us>
Precedence: bulk

Michael Paquier <michael.paquier@gmail.com> writes:
> On Sat, Nov 25, 2017 at 12:55 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I think that's a good thing to worry about.   In the past, Tom has
>> expressed reluctance to make stats tables that have a row per table
>> any wider at all, IIRC.

> Tom, any opinions to offer here? pg_stat_all_tables is currently at 22
> columns (this takes two full lines on my terminal with a font size at
> 13). With the first patch of what's proposed on this thread there
> would be 24 columns. Perhaps it would be time to split the vacuum
> statistics into a new view like pg_stat_tables_vacuum or similar?

My concern is not with the width of any view --- you can always select a
subset of columns if a view is too wide for your screen.  The issue is the
number of counters in the stats collector's state.  We know, without any
doubt, that widening PgStat_StatTabEntry causes serious pain to people
with large numbers of tables; and they have no recourse when we do it.
So the bar to adding more counters is very high IMO.  I won't say never,
but I do doubt that something like skipped vacuums should make the cut.

If we could get rid of the copy-to-a-temporary-file technology for
transferring the stats collector's data to backends, then this problem
would probably vanish or at least get a lot less severe.  But that seems
like a nontrivial project.  With the infrastructure we have today, we
could probably keep the stats tables in a DSM segment; but how would
a backend get a consistent snapshot of them?

			regards, tom lane