From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Craig James <craig_james(at)emolecules(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: SSD + RAID |
Date: | 2009-11-15 20:42:24 |
Message-ID: | 4B0067B0.2090407@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Craig James wrote:
> I've wondered whether this would work for a read-mostly application: Buy
> a big RAM machine, like 64GB, with a crappy little single disk. Build
> the database, then make a really big RAM disk, big enough to hold the DB
> and the WAL. Then build a duplicate DB on another machine with a decent
> disk (maybe a 4-disk RAID10), and turn on WAL logging.
>
> The system would be blazingly fast, and you'd just have to be sure
> before you shut it off to shut down Postgres and copy the RAM files back
> to the regular disk. And if you didn't, you could always recover from
> the backup. Since it's a read-mostly system, the WAL logging bandwidth
> wouldn't be too high, so even a modest machine would be able to keep up.
Should work, but I don't see any advantage over attaching the RAID array
directly to the 1st machine with the RAM and turning synchronous_commit=off.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Eddy Escardo-Raffo | 2009-11-15 22:51:26 | Unexpected sequential scan on an indexed column |
Previous Message | Craig James | 2009-11-15 19:53:22 | Re: SSD + RAID |