From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Hannu Krosing <hannu(at)skype(dot)net>, postgres hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: vacuum, performance, and MVCC |
Date: | 2006-06-26 14:58:44 |
Message-ID: | 20060626145844.GI24611@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2006-06-26 14:58:53 | Re: vacuum, performance, and MVCC |
Previous Message | Tom Lane | 2006-06-26 14:56:59 | Re: "Truncated" tuples for tuple hash tables |