bruce wrote:
> 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.
Here is an overview of the SITC method:
http://momjian.us/cgi-bin/pgsitc
Anyone want to start coding?
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
