Re: A couple thoughts about btree fillfactor - Mailing list pgsql-hackers

From mark@mark.mielke.cc
Subject Re: A couple thoughts about btree fillfactor
Date
Msg-id 20060710170925.GA18458@mark.mielke.cc
Whole thread Raw
In response to A couple thoughts about btree fillfactor  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: A couple thoughts about btree fillfactor  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Jul 10, 2006 at 12:36:34PM -0400, Tom Lane wrote:
> Now that the index options infrastructure is in, I am having a couple of
> second thoughts about the specific behavior that's been implemented,
> particularly for btree fillfactor.
> 1. The btree build code (nbtsort.c) is dependent on the assumption that
> the fillfactor is at least 2/3rds.  This is because we must put at least
> two keys in each page, and with maximally sized keys (1/3rd page) it
> might try to put only 0 or 1 tuple in a page if fillfactor is small.
> However, maximally sized keys are certainly a corner case, and in more
> usual situations a smaller fillfactor could be useful.  I'm thinking
> we could change the nbtsort.c code to work like "stop filling page
> when fillfactor is exceeded AND there are at least two entries already".
> Then any old fillfactor would work.

I like the idea. Do you think there should be a way of packing certain
indexes tighter, once they are known to be mostly read only? For
example, an option on REINDEX? This would free PostgreSQL to use a
smaller fillfactor while still allowing people to optimize those of
their tables that would benefit from a higher fillfactor once they
become mostly static?

> 3. What should the minimum fillfactor be?  The patch as submitted
> set the minimum to 50% for all relation types.  I'm inclined to
> think we should allow much lower fillfactors, maybe down to 10%.
> A really low fillfactor could be a good idea in a heavily updated
> table --- at least, I don't think we have any evidence to prove
> that it's not sane to want a fillfactor below 50%.

If there was a way of packing relations tighter, allowing much lower
fillfactors should be fine.

Cheers,
mark

-- 
mark@mielke.cc / markm@ncf.ca / markm@nortel.com     __________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
|\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   | 
|  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada
 One ring to rule them all, one ring to find them, one ring to bring them all                      and in the darkness
bindthem...
 
                          http://mark.mielke.cc/



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: lastval exposes information that currval does not
Next
From: "Florian G. Pflug"
Date:
Subject: Warm-Standby using WAL archiving / Seperate pg_restorelog application