Re: vacuum, performance, and MVCC

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: PFC <lists(at)peufeu(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: vacuum, performance, and MVCC
Date: 2006-06-27 18:37:32
Message-ID: 200606271837.k5RIbW522076@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark wrote:
>
> Bruce Momjian <bruce(at)momjian(dot)us> writes:
>
> > PFC wrote:
> > >
> > > > My idea is that if an UPDATE places the new tuple on the same page as
> > > > the old tuple, it will not create new index entries for any indexes
> > > > where the key doesn't change.
> > >
> > > Basically the idea behind preventing index bloat by updates is to have
> > > one index tuple point to several actual tuples having the same value.
> > >
> >
> > The idea is not to avoid index bloat, but to allow heap reuse, and having
> > one index entry for multiple versions of an UPDATEd row is merely an
> > implementation detail.
>
> It sort of sounds like you're describing a whole new index type that stores
> only the page, not the precise record of any tuple it indexes. If your table

Background, indexes point to page item pointers, not to actual offsets
in the page. This is how vacuum can move around tuples without modifying the
indexes. The index points to a page item pointer that is a chain of
tuples with the same indexed columns.

--
Bruce Momjian bruce(at)momjian(dot)us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2006-06-27 18:41:56 Re: posix_fadvise versus old kernels
Previous Message Bruce Momjian 2006-06-27 18:34:41 Re: [COMMITTERS] pgsql: Disallow changing/dropping default