Re: New FSM allocation policy

Heikki Linnakangas wrote:
> 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.

One other thing to keep in mind is that VACUUM can reduce a table's size
if the trailing blocks are empty, so there is some gain if the earlier
parts of the table are preferred for inserts.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +