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