On Mon, 2004-04-26 at 17:24, Manfred Koizar wrote:
On Mon, 26 Apr 2004 14:29:58 +0100, Simon Riggs 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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 7 | next ›
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedApr 25, '04 at 9:31p
activeApr 28, '04 at 9:14a
posts7
users4
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase