From: | Vadim Mikheev <vadim(at)krs(dot)ru> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | kar(at)webline(dot)dk, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] Priorities for 6.6 |
Date: | 1999-06-07 02:55:02 |
Message-ID: | 375B3486.A6C817E8@krs.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
> 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.
> 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.
Vadim
From | Date | Subject | |
---|---|---|---|
Next Message | Vadim Mikheev | 1999-06-07 02:59:25 | Re: [HACKERS] 6.6 items |
Previous Message | Bruce Momjian | 1999-06-07 02:43:20 | 6.6 items |