Re: vacuum, performance, and MVCC - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: vacuum, performance, and MVCC
Date
Msg-id 1151397605.3516.13.camel@localhost.localdomain
Whole thread Raw
In response to Re: vacuum, performance, and MVCC  (Hannu Krosing <hannu@skype.net>)
Responses Re: vacuum, performance, and MVCC  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Ühel kenal päeval, T, 2006-06-27 kell 10:38, kirjutas Hannu Krosing:
> Ühel kenal päeval, E, 2006-06-26 kell 23:08, kirjutas Bruce Momjian:
> > Jim C. Nasby wrote:
> > > On Mon, Jun 26, 2006 at 02:32:59PM -0400, Bruce Momjian wrote:
> > > > 
> > > > It is certainly possible to do what you are suggesting, that is have two
> > > > index entries point to same chain head, and have the index access
> > > > routines figure out if the index qualifications still hold, but that
> > > > seems like a lot of overhead.
> 
> I think Jim meant not 2 pointing to the same head, but 2 pointing into
> the same chain. Say we have table with (id serial, ts timestamp) where
> ts changes at each update and id does not.
> 
> So after 3 updates on one page we have one CITC/ITPC head with pointers
> from both indexes and two follow-up tuples with pointers from only ts
> index.
> 
> The problem with this setup is, that we can't reuse any of those
> follow-up tuples without index cleanup.

But we still have to think about similar cases (index entries pointing
inside CITC chains), unless we plan to disallow adding indexes to
tables.

Perhaps that case has to simply disable heap tuple reuse until some
event. what would that event be?

Or maybe we should have some bitmap of dirty tuple ids inside each page,
that is tuple ids that have index pointers to them. and then avoid using
these ?

-- 
----------------
Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com



pgsql-hackers by date:

Previous
From: PFC
Date:
Subject: Re: vacuum, performance, and MVCC
Next
From: Kim Bisgaard
Date:
Subject: Re: Table clustering idea