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

-- 
[EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]     
__________________________
.  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | 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 bind them...

                           http://mark.mielke.cc/


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq

Reply via email to