| From: | david(at)lang(dot)hm |
|---|---|
| To: | James Mansion <james(at)mansionfamily(dot)plus(dot)com> |
| Cc: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Luke Lonergan <LLonergan(at)greenplum(dot)com>, glynastill(at)yahoo(dot)co(dot)uk, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: SSD performance |
| Date: | 2009-01-27 07:51:33 |
| Message-ID: | alpine.DEB.1.10.0901262349490.16162@asgard.lang.hm |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, 27 Jan 2009, James Mansion wrote:
> Craig Ringer wrote:
>> These devices would be interesting for a few uses, IMO. One is temp
>> table space and sort space in Pg. Another is scratch space for apps
>> (like Photoshop) that do their own VM management. There's also potential
>>
> Surely temp tables and sort space isn't subject to fsync and won't gain that
> much since they
> should stay in the OS cache? The device will surely help seek- or sync-bound
> tasks.
>
> Doesn't that make it a good candidate for WAL and hot tables?
it doesn't just gain on fsync speed, but also raw transfer speed.
if everything stays in the OS buffers than you are right, but when you
start to exceed those buffers is when fast storage like this is very
useful.
David Lang
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2009-01-27 08:14:06 | Re: Odd behavior with temp usage logging |
| Previous Message | Josh Berkus | 2009-01-27 06:53:09 | Odd behavior with temp usage logging |