Heikki Linnakangas <[EMAIL PROTECTED]> writes: > 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
Starting from an arbitrary block that would be on average a 16MB stripe. One idea, we could scan the rest of the current page and use the first match. Another, given the way your tree structure works you can also descend the tree with a "target" page. You can find the first page with enough free space after the target page if there are any. (Take left branch if it's > target and has enough free space else take right branch if there's enough free space else take left branch). -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
