Re: [HACKERS] Priorities for 6.6

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

In response to

Responses

Browse pgsql-hackers by date

  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