The way my rewritten FSM works at the moment is that pages are handed
out of the FSM in random order, to spread the load of multiple backends
to different pages. That's good for spreading the load, but it occurred
to me while observing a test case that inserts a lot of rows to an
almost empty table with plenty of free space, that that sucks for the
case of a single backend populating a table. Currently, FSM will hand
out pages in sequential order, so from OS point of view we're reading
and writing the pages sequentially. If the pages are handed out in
random order, we'll do random I/O instead.
Fortunately there's an easy fix for that. If we optimize
RecordAndGetPageWithFreeSpace so that it will always return the next
page if it has enough space, we'll be doing sequential I/O again. That's
trivial as long as the next heap page is on the same FSM page, and
probably not too hard even if it's not. If we limit this optimization to
within the same FSM page, we'll effectively be filling fully a 32MB stripes
Thoughts?
I'm running more tests, and there's more issues that need discussion,
but I'll start separate threads for each. I'll also post an updated
patch separately.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
