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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
