Re: table/index fillfactor control, try 2
От | Simon Riggs |
---|---|
Тема | Re: table/index fillfactor control, try 2 |
Дата | |
Msg-id | 1150705901.2691.1073.camel@localhost.localdomain обсуждение исходный текст |
Ответ на | Re: table/index fillfactor control, try 2 (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>) |
Ответы |
Re: table/index fillfactor control, try 2
|
Список | pgsql-patches |
On Mon, 2006-06-19 at 14:36 +0900, ITAGAKI Takahiro wrote: > Simon Riggs <simon@2ndquadrant.com> wrote: > > > > 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. > > Presently, I suppose the parameters are not modified so many times. > They are set only on build time or maintenance. > > I think we will need metapages in the future, but not right now. If we will > provide an automatic configurator for fillfactors (or other parameters), > parameters might be changed every time the configurator runs, for example, > per autovacuum. Yes, I can see that future too. > > The metagpages thought would require some consolidation from various > > other proposals, so we'll need to wait for wider discussion on that. > > I agree, but it is easy to move the metadata from catalog to metapages. > So the metapages thought can be reconciled among proposals that must need it. > (pg_class_nt and dead tuples bitmaps?) I've copied in Alvaro to comment on possible cross-overs between these projects... Looks like we've got a class of data that is similar in its frequency of change to the pg_class_nt stuff. Also, the discussion about having some of this type of info cached in shared memory seems to have dried up. Should we now go for pg_class_nt plus shared memory cache? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
В списке pgsql-patches по дате отправления: