Bruce Momjian wrote:
>
> >
> > > Also, for 6.6, I am going to add system table indexes so all cache
> > > lookups use indexes. I am unsure that shared catalog cache is going to
> > > do that buffer cache doesn't already do. Perhaps if we just flushed the
> > > system table cache buffers less frequently, there would be no need for a
> > > shared system cache.
> >
> > I would like to see ntuples and npages in pg_class up-to-date.
> > Now we do fseek for each heap_insert and for each heap_beginscan.
> > And note that we have to open() system relation files, even
> > if pages are in buffer pool.
>
> Why do we have to open system tables if already in buffer cache? I
> guess so in case we need to write it out, or fault on another page.
Just because of ... heap_open()->RelationBuildDesc() does it.
Maybe we could delay smgropen?
But in any case note that big guys have shared catalog cache,
and this is not because of they haven't good buffer pool -:)
Keeping page in pool for just single row is not good.
"Oracle itself accesses the data dictionary frequently during
the parsing of SQL statements. This access is essential to the
continuing operation of Oracle. See Chapter 8, "The Data Dictionary,"
for more information on the data dictionary.
...
Caching of the Data Dictionary for Fast Access
Because Oracle constantly accesses the data dictionary during database
operation to validate user access and to verify the state of objects,
much of the data dictionary information is cached in the SGA. All
information is stored in memory using the LRU (least recently
used) algorithm. Information typically kept in the caches is that
required for parsing."
Vadim