Florin Andrei wrote:
On Wed, 2005-03-30 at 19:59 -0600, John Arbash Meinel wrote:
Put pg_xlog onto the same drive as the OS, not the drive with the database.
I forgot to mention: the OS drive is purposefully made very slow - the write cache is turned off and the FS is Ext3 with data=journal. Is then still ok to put pg_xlog on it?
The reason: if the power cord is yanked, the OS _must_ boot back up in good condition. If the DB is corrupted, whatever, nuke it then re- initialize it. But the OS must survive act-of-god events.
No, there is no uninterruptible power supply. It sucks, but that's how it is. I cannot change that.
You don't want write cache for pg_xlog either. And you could always create a second partition that used reiserfs, or something like that.
If you have to survine "act-of-god" you probably should consider making the system into a RAID1 instead of 2 separate drives (software RAID should be fine).
'Cause a much worse act-of-god is having a drive crash. No matter what you do in software, a failed platter will prevent you from booting. RAID 1 at least means 2 drives have to die.
If you need insert speed, and can't do custom transactions at the application side, you could try creating a RAM disk for the insert table, and then create a cron job that bulk pulls it out of that table and inserts it into the rest of the system. That should let you get a super-fast insert speed, and the bulk copies should stay reasonably fast.
Just realize that if your cron job stops running, your machine will slowly eat up all of it's ram, and really not play nice. I think adding an extra hard-drive is probably the best way to boost performance and reliability, but if you have a $0 budget, this is a possibility.
John =:->
signature.asc
Description: OpenPGP digital signature