New FSM allocation policy

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