Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W9R9u-0004iS-P7 for pgsql-hackers@arkaria.postgresql.org; Sat, 01 Feb 2014 03:22:18 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1W9R9u-000700-8s for pgsql-hackers@arkaria.postgresql.org; Sat, 01 Feb 2014 03:22:18 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W9R9s-0006zn-68 for pgsql-hackers@postgresql.org; Sat, 01 Feb 2014 03:22:16 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1W9R9p-0005c0-7f for pgsql-hackers@postgresql.org; Sat, 01 Feb 2014 03:22:15 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1W9R9j-0001Zt-8M; Fri, 31 Jan 2014 22:22:07 -0500 Date: Fri, 31 Jan 2014 22:22:07 -0500 From: Bruce Momjian To: Robert Haas Cc: Andres Freund , Jim Nasby , Alvaro Herrera , Peter Geoghegan , Tom Lane , Andrew Dunstan , PostgreSQL-development Subject: Re: [PERFORM] encouraging index-only scans Message-ID: <20140201032207.GD31141@momjian.us> References: <20130906163056.GA13158@momjian.us> <20130906163647.GA626072@alap2.anarazel.de> <20130906170159.GB13158@momjian.us> <20130906191330.GA13193@momjian.us> <20130906222623.GC626072@alap2.anarazel.de> <20130907002908.GA12753@momjian.us> <20130907053449.GE626072@alap2.anarazel.de> <5238854F.5040708@nasby.net> <20130917231050.GD29545@awork2.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Pg-Spam-Score: -2.5 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On Thu, Sep 19, 2013 at 02:39:43PM -0400, Robert Haas wrote: > Right now, whether or not to autovacuum is the rest of a two-pronged > test. The first prong is based on number of updates and deletes > relative to table size; that triggers a regular autovacuum. The > second prong is based on age(relfrozenxid) and triggers a > non-page-skipping vacuum (colloquially, an anti-wraparound vacuum). > > The typical case in which this doesn't work out well is when the table > has a lot of inserts but few or no updates and deletes. So I propose > that we change the first prong to count inserts as well as updates and > deletes when deciding whether it needs to vacuum the table. We > already use that calculation to decide whether to auto-analyze, so it > wouldn't be very novel. We know that the work of marking pages > all-visible will need to be done at some point, and doing it sooner > will result in doing it in smaller batches, which seems generally > good. > > However, I do have one concern: it might lead to excessive > index-vacuuming. Right now, we skip the index vac step only if there > ZERO dead tuples are found during the heap scan. Even one dead tuple > (or line pointer) will cause an index vac cycle, which may easily be > excessive. So I further propose that we introduce a threshold for > index-vac; so that we only do index vac cycle if the number of dead > tuples exceeds, say 0.1% of the table size. > > Thoughts? Let the hurling of rotten tomatoes begin. Robert, where are we on this? Should I post a patch? -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers