pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Jim Nasby <jim@nasby.net>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Geoghegan <peter@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [PERFORM] encouraging index-only scans
Date: Tue, 17 Sep 2013 11:37:35 -0500
Message-ID: <5238854F.5040708@nasby.net> (raw)
In-Reply-To: <20130907053449.GE626072@alap2.anarazel.de>
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

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



view thread (64+ messages)  latest in thread

Message-ID: <5238854F.5040708@nasby.net>
Permalink:  ../5238854F.5040708@nasby.net/
Also on:    postgresql.org/message-id/5238854F.5040708@nasby.net

 · 

reply

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-performance@postgresql.org
  Cc: jim@nasby.net, andres@2ndquadrant.com, bruce@momjian.us, alvherre@2ndquadrant.com, robertmhaas@gmail.com, peter@2ndquadrant.com, tgl@sss.pgh.pa.us, andrew@dunslane.net, pgsql-hackers@postgresql.org
  Subject: Re: [PERFORM] encouraging index-only scans
  In-Reply-To: <5238854F.5040708@nasby.net>

* 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