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 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.
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 decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828