Greg Stark wrote:
> Bruce Momjian <[EMAIL PROTECTED]> 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   [EMAIL PROTECTED]

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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to