On Thu, Nov 3, 2011 at 8:27 PM, Jim Nasby <jim@nasby.net> wrote:
> On Nov 2, 2011, at 11:27 AM, Robert Haas wrote:
>> The following comment - or at least the last sentence thereof -
>> appears to be out of date.
>>
>> /*
>> * XXX Should we update the FSM information of this page ?
>> *
>> * There are two schools of thought here. We may not want to update FSM
>> * information so that the page is not used for unrelated
>> UPDATEs/INSERTs
>> * and any free space in this page will remain available for further
>> * UPDATEs in *this* page, thus improving chances for doing HOT updates.
>> *
>> * But for a large table and where a page does not receive
>> further UPDATEs
>> * for a long time, we might waste this space by not updating the FSM
>> * information. The relation may get extended and fragmented further.
>> *
>> * One possibility is to leave "fillfactor" worth of space in this page
>> * and update FSM with the remaining space.
>> *
>> * In any case, the current FSM implementation doesn't accept
>> * one-page-at-a-time updates, so this is all academic for now.
>> */
>>
>> The simple fix here is just to delete that last sentence, but does
>> anyone think we ought to do change the behavior, now that we have the
>> option to do so?
>
> The fillfactor route seems to make the most sense here... it certainly seems to be the least surprising behavior.
Seems a little hackish, though: we'd be reporting an amount of
freespace that we've deliberately set to an incorrect value. I'm
almost thinking we should report the freespace that's actually
available, on the theory that Bload Is Bad (TM).
Maybe some testing is in order.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company