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] EnterpriseDB http://www.enterprisedb.com + 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 match
