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. ... I'm thinking
we could change the nbtsort.c code
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
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
Ühel kenal päeval, E, 2006-07-10 kell 12:36, kirjutas Tom Lane:
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
On Mon, Jul 10, 2006 at 03:17:01PM -0400, Tom Lane wrote:
[EMAIL PROTECTED] writes:
... 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
[EMAIL PROTECTED] writes:
... 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
