From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Jan Wieck <JanWieck(at)yahoo(dot)com> |
Cc: | Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Experimental ARC implementation |
Date: | 2003-11-07 03:55:51 |
Message-ID: | 200311070355.hA73tpI07759@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jan Wieck wrote:
> If the system is write-bound, the checkpointer will find that many dirty
> blocks that he has no time to nap and will burst them out as fast as
> possible anyway. Well, at least that's the theory.
>
> PostgreSQL with the non-overwriting storage concept can never have
> hot-written pages for a long time anyway, can it? They fill up and cool
> down until vacuum.
Another idea on removing sync() --- if we are going to use fsync() on
each file during checkpoint (open, fsync, close), seems we could keep a
hash of written block dbid/relfilenode pairs and cycle through that on
checkpoint. We could keep the hash in shared memory, and dump it to a
backing store when it gets full, or just have it exist in buffer writer
process memory (so it can grow) and have backends that do their own
buffer writes all open a single file in append mode and write the pairs
to the file, or something like that, and the checkpoint process can read
from there.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2003-11-07 04:06:37 | CVS open for development? |
Previous Message | Bruce Momjian | 2003-11-07 03:48:29 | Re: Experimental ARC implementation |