On Mon, 2006-06-19 at 14:36 +0900, ITAGAKI Takahiro wrote:
> Simon Riggs <[EMAIL PROTECTED]> 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
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?
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not