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

Re: Block B-Tree concept

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block B-Tree concept
Date: 2006-09-29 14:39:25
Message-ID: 1159540765.2767.359.camel@holly (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, 2006-09-29 at 14:54 +0100, Heikki Linnakangas wrote:

> > The benefit we're seeking with a block index is that most INSERTs don't
> > write to the index. With that scheme we'd need to continually update the
> > index tuple so that it exactly represented the heap after each inserted
> > tuple, which is going to cause a hot block problem.
> 
> That's just one of the benefits. I think the main benefit is dramatic 
> reduction in index size which means that more of the index is cached.
> 
> An INSERT will have to find the corresponding leaf page anyway. Having 
> to dirty it isn't a big deal assuming that the hot blocks stay in cache.

The index tuple would potentially grow in length while we update it, so
that means we'd need exclusive access to write, rather than shared
access to just read the index.

-- 
  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com


In response to

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2006-09-29 14:55:20
Subject: Re: Block B-Tree concept
Previous:From: Tom LaneDate: 2006-09-29 14:31:02
Subject: Re: pgsql: Fix IS NULL and IS NOT NULL tests on row-valued expressions to

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