From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Cc: Sawada Masahiko <sawada.mshk@gmail.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Robert Haas <robertmhaas@gmail.com>
Subject: Re: [HACKERS] More stats about skipped vacuums
Date: Sat, 25 Nov 2017 10:34:24 -0500
Message-ID: <1323.1511624064@sss.pgh.pa.us> (raw)
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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, michael.paquier@gmail.com, horiguchi.kyotaro@lab.ntt.co.jp, sawada.mshk@gmail.com, robertmhaas@gmail.com
Subject: Re: [HACKERS] More stats about skipped vacuums
In-Reply-To: <1323.1511624064@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox