Re: table/index fillfactor control, try 2

On Fri, 2006-06-16 at 13:33 +0900, ITAGAKI Takahiro wrote:
> This is a revised fillfactor patch. It uses WITH syntax and
> we can add new AM specific parameters easily.

Cool. I'll look at that in more detail.

> > So we have a new element of the RelationData struct:
> >     void    *rd_amopts;
> > Which each AM defines and interprets.
>
> The internal structure is stored in the pg_class.relamopaque column as bytea.
> I guess it is not the best and there is room for discussion. I examined the
> following ideas, but they had complexities and difficulties.
>
>  1. Add AM specific system tables (pg_heap, pg_btree, etc.) that may inherit
>     pg_class. But it will impact the current source code terribly.

Hmmm, yep, not a good idea.

>  2. Store the structures in AM's meta page. But heaps don't have meta pages.

But perhaps they should? That sounds very similar to the idea of
non-transactional pg_class data.

It would make a lot of sense if heaps had meta pages too, and that the
data within them was cached on the relcache just as index meta page data
will be for 8.2

>  3. Store them into an array of text column that newly added to pg_class.
>     But we hove to re-parse the array every time relations are loaded.

Not sure if thats a big overhead? Is it a big array? I hope not. We
should be aiming for as few parameters as possible for an index/heap,
otherwise we'll never be able to determine their correct settings.

>  4. Add new system table, pg_class_option (relid, option name, value).
>     But it has same problem as 3 and needs additional heap scannings.

No thanks.

> Therefore, I choose the as-is binary format to store the internal structures.
> Any comments or better ideas?

Well, its either metapages or array-on-pg_class for me.

The metagpages thought would require some consolidation from various
other proposals, so we'll need to wait for wider discussion on that.

--
  Simon Riggs
  EnterpriseDB          http://www.enterprisedb.com