Simon Riggs <simon@2ndquadrant.com> writes:
> On Wed, 2005-04-20 at 09:03 -0400, Bruce Momjian wrote:
>> My guess is that the FILLFACTOR will actually be a GUC variable rather
>> than a clause to CREATE INDEX or REINDEX or CLUSTER.
> I hope not, but it would be easier to set like that and a lot easier to
> code up that way.
I don't like that either. It seems highly unlikely that every table in
a database would need the same fillfactor. It should be a per-table
attribute, maybe with a DB-wide default, much like we handle per-column
statistics targets.
My thought about this is that the case where extra free space really
helps is UPDATE: if heap_update can put the new tuple version on the
same page where the old one is, there's a noticeable savings. So what
you'd probably want is that heap_insert respects fillfactor (ie, won't
eat the last fillfactor percent of a page) but heap_update doesn't,
if it can thereby put the update on the same page. As long as you
vacuum before a particular page is entirely filled by updates of its
own tuples, you have a steady-state situation.
I don't see a lot of point in Hannu's suggestion about leaving every Nth
page free. Once you've had to move off the source page, near or far
makes little difference. It might win if we were also trying to teach
insert and update to preserve CLUSTER ordering --- but that is an order
of magnitude harder than what's been discussed in this thread, and I'm
unconvinced it's a good idea anyway ...
regards, tom lane
