| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Mitsuru IWASAKI <iwasaki(at)jp(dot)FreeBSD(dot)org> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: patch for new feature: Buffer Cache Hibernation |
| Date: | 2011-05-04 15:44:36 |
| Message-ID: | 12145.1304523876@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Mitsuru IWASAKI <iwasaki(at)jp(dot)FreeBSD(dot)org> writes:
> Postgres usually starts with ZERO buffer cache. By saving the buffer
> cache data structure into hibernation files just before shutdown, and
> loading them at startup, postgres can start operations with the saved
> buffer cache as the same condition as just before the last shutdown.
This seems like a lot of complication for rather dubious gain. What
happens when the DBA changes the shared_buffers setting, for instance?
How do you protect against the cached buffers getting out-of-sync with
the actual disk files (especially during recovery scenarios)? What
about crash-induced corruption in the cache file itself (consider the
not-unlikely possibility that init will kill the database before it's
had time to dump all the buffers during a system shutdown)? Do you have
any proof that writing out a few GB of buffers and then reading them
back in is actually much cheaper than letting the database re-read the
data from the disk files?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2011-05-04 15:51:57 | Re: Unlogged vs. In-Memory |
| Previous Message | Greg Stark | 2011-05-04 15:38:50 | Re: patch for new feature: Buffer Cache Hibernation |