From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org, Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Greg Smith <gsmith(at)gregsmith(dot)com>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, Decibel! <decibel(at)decibel(dot)org> |
Subject: | Re: Overhauling GUCS |
Date: | 2008-06-11 21:05:15 |
Message-ID: | 11913.1213218315@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Josh Berkus wrote:
>> Ideally, of course, there would be no wal_buffers setting, and WAL
>> buffers would be allocated from shared_buffers pool on demand...
> Same for pg_subtrans, pg_clog, etc (as previously discussed)
I agree with that for pg_clog and friends, but I'm much more leery of
folding WAL into the same framework. Its access pattern is *totally*
unlike standard caches, so the argument that this would be good for
performance is resting on nothing but imagination. Also I'm concerned
about possible deadlocks, because WAL is customarily accessed while
holding one or more exclusive buffer locks.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2008-06-11 21:11:48 | Re: How to Sponsor a Feature |
Previous Message | Bruce Momjian | 2008-06-11 20:54:23 | Re: Overhauling GUCS |