> Bruce Momjian wrote:
> >
> > update pg_log on disk. Another issue is that now that we update the
> > transaction status as part of SELECT, pg_log is not the only
>
> We should don't update pg_log for read-only xactions.
No, I was saying we mark those SELECT'ed rows as being part of committed
transactions. When we SELECT a row, we look at pg_log to see if it is
committed, and mark that row as part of a committed transaction so we
don't have to check pg_log again. We can't do that with the system we
invisioning until we put pg_log on disk as a committed transaction.
Could be tricky, though having two copies of pg_log in memory, one
disk-copy and one active copy, and use disk-copy for row xact status
updates would do the trick.
>
> > representation of committed status.
> >
> > Of course, we have to prevent flush of pglog by OS, perhaps by making a
> > copy of the last two pages of pg_log before this and remove it after.
> > If a backend starts up and sees that pg_log copy file, it puts that in
> > place of the current last two pages of pg_log.
>
> Keep two last pg_log pages in shmem, lock them, copy, unlock,
> write copy to pg_log.
Yes, much better. Control what gets to disk by not updating the file at
all.
>
> > 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.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026