On Thu, Aug 17, 2006 at 02:54:20PM -0500, Jim C. Nasby wrote:
> On Thu, Aug 17, 2006 at 02:23:48PM +0200, Martijn van Oosterhout wrote:
> > On Thu, Aug 17, 2006 at 12:55:28PM +0900, ITAGAKI Takahiro wrote:
> > > But the method has the above problem. So I suggest to use whether
> > > the right link points to the next adjacent page or not.
> > >
> > > if (opaque->btpo_next != P_NONE && opaque->btpo_next != blkno + 1)
> > > stat->fragments++;
> > >
> > > Do you think which method is better? Or do you have other ideas?
>
> Ok, fine... expand the example out to an index that's not trivial in
> size. Even with read-ahead, once you get to a few megs (which is
> obviously not that big), you're seeking.
Well, mostly I'm just saying that only matching on the next block
number is going to give unrealistically low numbers. We can't ignore OS
level caching, the way Postgres works relies on it in many ways.
I'd suggest something like: btpo_next between blkno and blkno + X, to
try to take into account caching. But I'm not sure that will give
numbers significantly different from what is already generated.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.