From: | Kenneth Marshall <ktm(at)it(dot)is(dot)rice(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: A couple thoughts about btree fillfactor |
Date: | 2006-07-10 17:01:14 |
Message-ID: | 20060710170114.GM15796@it.is.rice.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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. ... 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.
>
> 2. ... There's a case to be made for making
> leaf and non-leaf fillfactors accessible as separate knobs, but I'm
> inclined just to use a fixed value of 70 for non-leaf factor....
>
> 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%.
>
> Comments?
>
> regards, tom lane
I would like to place my vote for supporting fillfactors less than
50%. Like you mentioned, a heavily updated table could be forced to
a page split before VACUUM freed the items and made them available
for reuse. I also think that points 1 and 2 are reasonable.
Ken
From | Date | Subject | |
---|---|---|---|
Next Message | mark | 2006-07-10 17:09:26 | Re: A couple thoughts about btree fillfactor |
Previous Message | Bruce Momjian | 2006-07-10 16:49:54 | Re: lastval exposes information that currval does not |