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

Re: table/index fillfactor control, try 2

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: table/index fillfactor control, try 2
Date: 2006-06-16 20:08:57
Message-ID: 1150488537.2587.58.camel@localhost.localdomain (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
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

In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2006-06-16 20:33:38
Subject: Re: [COMMITTERS] pgsql: Add STRICT to PL/pgSQL SELECT INTO, so exceptions
Previous:From: Tom LaneDate: 2006-06-16 20:06:46
Subject: Re: [COMMITTERS] pgsql: Add STRICT to PL/pgSQL SELECT INTO, so exceptions are thrown if

pgsql-patches by date

Next:From: Andrew DunstanDate: 2006-06-16 20:25:32
Subject: Re: drop if exists remnainder (reprise)
Previous:From: Bruce MomjianDate: 2006-06-16 20:05:21
Subject: Re: [Win32] Problem with rename()

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