Message-ID: <5238854F.5040708@nasby.net>
Date: Tue, 17 Sep 2013 11:37:35 -0500
From: Jim Nasby <jim@nasby.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Andres Freund <andres@2ndquadrant.com>
CC: Bruce Momjian <bruce@momjian.us>,
 Alvaro Herrera <alvherre@2ndquadrant.com>,
 Robert Haas <robertmhaas@gmail.com>,
 Peter Geoghegan <peter@2ndquadrant.com>,
 Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [PERFORM] encouraging index-only scans
References: 
 <CA+Tgmobh_-n-GvKX++DVctToZ9SZkdhvszP=CBjh9XZOvWsTEg@mail.gmail.com>
 <20130906020043.GH27195@momjian.us>
 <20130906052236.GF6067@eldon.alvh.no-ip.org>
 <20130906130854.GB600952@alap2.anarazel.de>
 <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>
In-Reply-To: <20130907053449.GE626072@alap2.anarazel.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 9/7/13 12:34 AM, Andres Freund wrote:
> What I was thinking of was to keep track of the oldest xids on pages
> that cannot be marked all visible. I haven't thought about the
> statistics part much, but what if we binned the space between
> [RecentGlobalXmin, ->nextXid) into 10 bins and counted the number of
> pages falling into each bin. Then after the vacuum finished we could
> compute how far RecentGlobalXmin would have to progress to make another
> vacuum worthwile by counting the number of pages from the lowest bin
> upwards and use the bin's upper limit as the triggering xid.
>
> Now, we'd definitely need to amend that scheme by something that handles
> pages that are newly written to, but it seems something like that
> wouldn't be too hard to implement and would make autovacuum more useful.

If we're binning by XID though you're still dependent on scanning to build that range. Anything that creates dead tuples will also be be problematic, because it's going to unset VM bits on you, and you won't know if it's due to INSERTS or dead tuples.

What if we maintained XID stats for ranges of pages in a separate fork? Call it the XidStats fork. Presumably the interesting pieces would be min(xmin) and max(xmax) for pages that aren't all visible. If we did that at a granularity of, say, 1MB worth of pages[1] we're talking 8 bytes per MB, or 1 XidStats page per GB of heap. (Worst case alignment bumps that up to 2 XidStats pages per GB of heap.)

Having both min(xmin) and max(xmax) for a range of pages would allow for very granular operation of vacuum. Instead of hitting every heap page that's not all-visible, it would only hit those that are not visible and where min(xmin) or max(xmax) were less than RecentGlobalXmin.

One concern is maintaining this data. A key point is that we don't have to update it every time it changes; if the min/max are only off by a few hundred XIDs there's no point to updating the XidStats page. We'd obviously need the XidStats page to be read in, but even a 100GB heap would be either 100 or 200 XidStats pages.

[1]: There's a trade-off between how much space we 'waste' on XidStats pages and how many heap pages we potentially have to scan in the range. We'd want to see what this looked like in a real system. The thing that helps here is that regardless of what the stats for a particular heap range are, you're not going to scan any pages in that range that are already all-visible.
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers