| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2006-09-29 14:55:20 | Re: Block B-Tree concept |
| Previous Message | Tom Lane | 2006-09-29 14:31:02 | Re: pgsql: Fix IS NULL and IS NOT NULL tests on row-valued expressions to |