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