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

From Hannu Krosing
Subject Re: vacuum, performance, and MVCC
Date
Msg-id 1151334958.3885.33.camel@localhost.localdomain
Whole thread Raw
In response to Re: vacuum, performance, and MVCC  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Ühel kenal päeval, E, 2006-06-26 kell 16:58, kirjutas Martijn van
Oosterhout:
> On Mon, Jun 26, 2006 at 10:50:26AM -0400, Bruce Momjian wrote:
> > > > I suppose we would also change the index_getmulti() function to return
> > > > a set of ctids plus flags so the caller knows to follow the chains,
> > > > right? 
> > > 
> > > It is probably better to always return the pointer to the head of CITC
> > > chain (the one an index points to) and do extra visibility checks and
> > > chain-following on each access. This would keep the change internal to
> > > tuple fetching functions.
> > 
> > So index_getnext() traverses the chain and returns one member per call. 
> > Makes sense.  Just realize you are in a single index entry returning
> > multiple tuples.  We will need some record keeping to track that.
> 
> Yes, and for index_getmulti (which doesn't visit the heap at all) we'll
> have to change all the users of that (which aren't many, I suppose).
> It's probably worth making a utility function to expand them.
> 
> I'm still confused where bitmap index scan fit into all of this. Is
> preserving the sequential scan aspect of these a goal with this new
> setup?

Bitmap index scan does not have to change much - only the function that
gets tuple by its ctid must be able to trace forward chains within the
page.

-- 
----------------
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: Robert Treat
Date:
Subject: Re: Anyone still care about Cygwin? (was Re: [CORE] GPL
Next
From: "Bort, Paul"
Date:
Subject: Re: "Truncated" tuples for tuple hash tables