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
