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 <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
