| From: | david(at)lang(dot)hm |
|---|---|
| To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
| Cc: | Laurent Laborde <kerdezixe(at)gmail(dot)com>, Ivan Voras <ivoras(at)freebsd(dot)org>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: limiting performance impact of wal archiving. |
| Date: | 2009-11-15 22:54:42 |
| Message-ID: | alpine.DEB.2.00.0911151454140.6163@asgard.lang.hm |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, 10 Nov 2009, Greg Smith wrote:
> Laurent Laborde wrote:
>> It is on a separate array which does everything but tablespace (on a
>> separate array) and indexspace (another separate array).
>>
> On Linux, the types of writes done to the WAL volume (where writes are
> constantly being flushed) require the WAL volume not be shared with anything
> else for that to perform well. Typically you'll end up with other things
> being written out too because it can't just selectively flush just the WAL
> data. The whole "write barriers" implementation should fix that, but in
> practice rarely does.
I believe that this is more a EXT3 problem than a linux problem.
David Lang
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2009-11-15 23:05:50 | Re: Unexpected sequential scan on an indexed column |
| Previous Message | Eddy Escardo-Raffo | 2009-11-15 22:51:26 | Unexpected sequential scan on an indexed column |