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

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 (view raw or flat)
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

pgsql-hackers by date

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

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