From: Tom Lane <tgl@sss.pgh.pa.us>
To: Magnus Hagander <magnus@hagander.net>
cc: Robert Haas <robertmhaas@gmail.com>,
        Michael Paquier <michael.paquier@gmail.com>,
        Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>,
        Sawada Masahiko <sawada.mshk@gmail.com>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] More stats about skipped vacuums
In-reply-to: 
 <CABUevEyW5hhf_cacw3uRY+a4+2J2tk2mTvfdcCikFj6mf5W-cg@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>
 <1323.1511624064@sss.pgh.pa.us>
 <CA+TgmoYZTHCFZzPrz8tG9TQknAd=MsacTy7aT2ttia=dRB2eGQ@mail.gmail.com>
 <2077.1511629794@sss.pgh.pa.us>
 <CA+TgmoZH9LFhxX9r0hqrMN7eBySNabb5jkV4H9hcxyAcj2gnkA@mail.gmail.com>
 <1451.1511727581@sss.pgh.pa.us>
 <CA+TgmoZUjVh=R-9+ThtvZMNEsxbeASySJ2JER2+3B1bUeDabbg@mail.gmail.com>
 <CABUevEyW5hhf_cacw3uRY+a4+2J2tk2mTvfdcCikFj6mf5W-cg@mail.gmail.com>
Comments: In-reply-to Magnus Hagander <magnus@hagander.net>
	message dated "Mon, 27 Nov 2017 22:05:06 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23559.1511824566.1@sss.pgh.pa.us>
Date: Mon, 27 Nov 2017 18:16:06 -0500
Message-ID: <23560.1511824566@sss.pgh.pa.us>
Precedence: bulk

Magnus Hagander <magnus@hagander.net> writes:
> What I've been thinking about for that one before is if we could just
> invent a protocol (shmq based maybe) whereby autovacuum can ask the stats
> collector for a single table or index stat. If autovacuum never needs to
> see a consistent view between multiple tables, I would think that's going
> to be a win in a lot of cases.

Perhaps.  Autovac might run through quite a few tables before it finds
one in need of processing, though, so I'm not quite certain this would
yield such great benefits in isolation.

> However, when it comes to the stats system, I'd say that on any busy system
> (which would be the ones to care about), the stats structures are still
> going to be *written* a lot more than they are read.

Uh, what?  The stats collector doesn't write those files at all except
on-demand.

			regards, tom lane