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

Re: vacuum, performance, and MVCC

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: PFC <lists(at)peufeu(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: vacuum, performance, and MVCC
Date: 2006-06-27 18:28:43
Message-ID: 87k672wizo.fsf@stark.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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
has only such indexes then you never need to worry about updating indexes if
your new tuple version goes on the same page as the old one.

It's an interesting thought experiment. It might trade off a lot of work in
index maintenance as well as saving space in the index for a lot of additional
work performing index scans. There can easily be enough tuples on a page to
make scanning the entire page pretty costly.


-- 
greg


In response to

Responses

pgsql-hackers by date

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

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