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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-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
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2006-06-16 20:33:38 | Re: [COMMITTERS] pgsql: Add STRICT to PL/pgSQL SELECT INTO, so exceptions |
Previous Message | Tom Lane | 2006-06-16 20:06:46 | Re: [COMMITTERS] pgsql: Add STRICT to PL/pgSQL SELECT INTO, so exceptions are thrown if |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-06-16 20:25:32 | Re: drop if exists remnainder (reprise) |
Previous Message | Bruce Momjian | 2006-06-16 20:05:21 | Re: [Win32] Problem with rename() |