Skip site navigation (1) Skip section navigation (2)

Re: Rethinking hint bits WAS: Protecting against unexpected zero-pages: proposal

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Rethinking hint bits WAS: Protecting against unexpected zero-pages: proposal
Date: 2010-11-14 20:52:39
Message-ID: 4CE04C17.9050601@agliodbs.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> If we got rid of hint bits, we'd need workarounds for the ensuing
> massive performance loss.  There is no reason whatsoever to imagine
> that we'd come out ahead in the end.

Oh, there's no question that we need something which serves the same
purpose as the existing hit bits.  But there's a lot of question about
whether our existing implementation is optimal.

For example, imagine if the hint bits were moved to a separate per-table
bitmap outside the table instead of being stored with each row, as the
current FSM is.  Leaving aside the engineering required for this (which
would be considerable, especially when it comes to consistency and
durability), this would potentially allow solutions to the following issues:

* Index-only access
* I/O associated with hint bit setting
* Vacuum freezing old-cold data
* Page-level CRCs
* Rsyncing tables for replication

Alternately, we could attack this by hint bit purpose.  For example, if
we restructured the CLOG so that it was an efficient in-memory index
(yes, I'm being handwavy), then having the XID-is-visible hint bits
might become completely unnecessary.  We could then also improve the
visibility map to be reliable and include "frozen" bits as well.

Overall, what I'm pointing out is that our current implementation of
hint bits is blocking not one by several major features and causing our
users performance pain.  It's time to look for an implementation which
doesn't have the same problems we're familiar with.

-- 
                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.
                                     http://www.pgexperts.com

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-11-14 20:55:33
Subject: Re: max_wal_senders must die
Previous:From: Greg SmithDate: 2010-11-14 20:49:24
Subject: pg_stat_bgwriter broken?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group