| From: | Greg Smith <greg(at)2ndquadrant(dot)com> |
|---|---|
| To: | Jignesh Shah <jkshah(at)gmail(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: PostgreSQL as a local in-memory cache |
| Date: | 2010-07-01 10:00:01 |
| Message-ID: | 4C2C6721.2010000@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On 6/30/2010 2:21 PM, Jignesh Shah wrote:
> If the underlying WAL disk is SSD then it seems I can get
> synchronous_commit=on to work faster than
> synchronous_commit=off..
The first explanation that pops to mind is that synchronous_commit is
writing all the time, which doesn't have the same sort of penalty on
SSD. Whereas if you turn it off, then there are some idle periods where
the SSD could be writing usefully, but instead it's buffering for the
next burst instead. The importance of that can be magnified on
operating systems that do their own buffering and tend to lag behind
writes until they see an fsync call, like is the case on Linux with ext3.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rajesh Kumar Mallah | 2010-07-01 12:40:18 | Re: What is the best way to optimize this query |
| Previous Message | Rajesh Kumar Mallah | 2010-07-01 09:49:49 | Re: Extremely high CPU usage when building tables |