Re: New FSM allocation policy - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: New FSM allocation policy
Date
Msg-id 48CB64EF.9080406@enterprisedb.com
Whole thread Raw
In response to Re: New FSM allocation policy  (Decibel! <decibel@decibel.org>)
List pgsql-hackers
Decibel! wrote:
> On Sep 5, 2008, at 9:43 PM, Bruce Momjian wrote:
>> 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.

Not sure how exactly that should work, but it should be pretty easy to 
do with the new FSM data structure. Perhaps VACUUM should just reset the 
"next pointers" as it goes.

> 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).

The new FSM data structure should make that much easier to implement as 
well, as it supports naturally the operation "give me page with X bytes 
of free space, as close as possible to page Y".

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Decibel!
Date:
Subject: Re: Noisy CVS updates
Next
From: Heikki Linnakangas
Date:
Subject: Re: PLUGINS Functionlity in Win32 build scripts