On Sep 5, 2008, at 9:43 PM, Bruce Momjian wrote:
Fortunately there's an easy fix for that. If we optimize RecordAndGetPageWithFreeSpace so that it will always return the nextpage if it has enough space, we'll be doing sequential I/O again. That'strivial as long as the next heap page is on the same FSM page, andprobably 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 stripesThoughts? 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 sizeif the trailing blocks are empty, so there is some gain if the earlier parts of the table are preferred for inserts.
Yeah; I would actually really, really like to see a mode you could set on a table that says "I want to try and shrink this table". One of the things that would mean is that the FSM should prefer pages at the beginning of the heap.
Also related to this is the idea of asking the FSM for pages within a specific range so that you can try and maintain cluster order on a table. You would look in the clustering index for the closest value to your key and where it is in the heap and then ask for a page in that neighborhood. (You'd probably want to look at more than just one index tuple, but you get the idea).
-- Decibel!, aka Jim C. Nasby, Database Architect [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828
smime.p7s
Description: S/MIME cryptographic signature
