Skip site navigation (1) Skip section navigation (2)

Re: TODO-Item: B-tree fillfactor control

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: TODO-Item: B-tree fillfactor control
Date: 2006-02-01 17:45:11
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
ITAGAKI Takahiro wrote:
> Hi Hackers,
> I'm trying the following TODO item:
>   [Indexes]
>     - Add fillfactor to control reserved free space during index creation 
> I have already made an patch and it seemed to work well.


> And now, I need advice on some issues.
> - Is it appropriate to use GUC variables to control fillfactors?
>     Is it better to extend CREATE INDEX / REINDEX grammar?

I think it has to be part of CREATE INDEX and ALTER INDEX.

Is there a use for separate node and leaf settings?

This patch needs documentation, and if we have separate items, we are
going to have to explain when to use node or leaf.

> - Should indexes remember their fillfactors when they are created?
>     The last fillfactors will be used on next reindex.

They should remember, for sure, and REINDEX should use it.  It think
this is similar to the ALTER TABLE ALTER [ COLUMN ] ... SET STATISTICS 
functionality.  It will need to be dumped as well by pg_dump.  If you
need help with any of this, let me know.

> - Is fillfactor useful for hash and gist indexes?
>     I think hash does not need it, but gist might need it.

Not sure.  We don't know what type of index a GIST will be so we have no
way of knowing.  I am thinking we can implement just btree now and the
GIST folks can add it later if they want.  My guess is that each GIST is
going to behave differently for different fill-factors, so if allow it
to be set for GIST, GIST developers can pull the value if they want.

  Bruce Momjian                        |
  pgman(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-02-01 17:47:09
Subject: Re: log_min_messages and debug levels
Previous:From: Matthew T. O'ConnorDate: 2006-02-01 17:43:32
Subject: Re: [HACKERS] autovacuum

pgsql-patches by date

Next:From: Tom LaneDate: 2006-02-01 18:22:17
Subject: Re: TODO-Item: B-tree fillfactor control
Previous:From: Bruce MomjianDate: 2006-02-01 17:23:54
Subject: Re: [HACKERS] Bug: random() can return 1.0

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group