On Mon, 2004-04-26 at 17:24, Manfred Koizar wrote:
> On Mon, 26 Apr 2004 14:29:58 +0100, Simon Riggs <simon@2ndquadrant.com>
> wrote:
> >> Now that FSM
> >> covers free btree index pages this access pattern might be highly
> >> nonsequential.
> >
> >I had considered implementing a mode where the index doesn't keep trying
> >to reuse space that was freed by earlier deletes.
>
> Or maybe an FSM function a la "Give me a free page near this one"?
>
I think you're statement of the requirement is better, but I suspect
more complex to implement.
Overall, my feeling about the index code is:
- its based upon the earlier Lehman-Yao coding and we know better than
that now...various literature
- the b-tree code is written with the assumption that the
inserts/deletes are more or less randomly distributed and balanced, as
is the case with TPC-B
- I would prefer a mode where the case of large table inserts - the
HISTORY table in TPC-B, or many of the tables in TPC-H was optimised for
- so inserts on the leading edge of the index go faster, bulk deletes go
faster, but we take the chance that space is not reclaimed effectively
by random deletes.
Best Regards, Simon Riggs
