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
+ If your life is a hard drive, Christ can be your backup. +
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2006-06-27 18:41:56|
|Subject: Re: posix_fadvise versus old kernels|
|Previous:||From: Bruce Momjian||Date: 2006-06-27 18:34:41|
|Subject: Re: [COMMITTERS] pgsql: Disallow changing/dropping default|