Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtp (Exim 4.84_2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1eIdxw-0005ZN-6n
	for pgsql-hackers@arkaria.postgresql.org; Sat, 25 Nov 2017 17:10:08 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.84_2)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1eIdxv-0001JU-Gu
	for pgsql-hackers@arkaria.postgresql.org; Sat, 25 Nov 2017 17:10:07 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.84_2)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1eIdxv-0001JC-Aa
	for pgsql-hackers@lists.postgresql.org; Sat, 25 Nov 2017 17:10:07 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256)
	(Exim 4.89)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1eIdxn-0002bJ-LY
	for pgsql-hackers@postgresql.org; Sat, 25 Nov 2017 17:10:06 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id vAPH9seg002078;
	Sat, 25 Nov 2017 12:09:54 -0500
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: 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: 
 <CA+TgmoYZTHCFZzPrz8tG9TQknAd=MsacTy7aT2ttia=dRB2eGQ@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>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Sat, 25 Nov 2017 11:10:30 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2076.1511629794.1@sss.pgh.pa.us>
Date: Sat, 25 Nov 2017 12:09:54 -0500
Message-ID: <2077.1511629794@sss.pgh.pa.us>
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> Of course, the other obvious question is whether we really need a
> consistent snapshot, because that's bound to be pretty expensive even
> if you eliminate the I/O cost.  Taking a consistent snapshot across
> all 100,000 tables in the database even if we're only ever going to
> access 5 of those tables doesn't seem like a good or scalable design.

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.

What we need is a way to have a consistent snapshot without implementing
it by copying 100,000 tables' worth of data for every query.  Hmm, I heard
of a technique called MVCC once ...

			regards, tom lane