[GENERAL] Help tuning a large table off disk and into RAM

2007-09-26 Thread James Williams
I'm stuck trying to tune a big-ish postgres db and wondering if anyone has any pointers. I cannot get Postgres to make good use of plenty of available RAM and stop thrashing the disks. One main table. ~30 million rows, 20 columns all integer, smallint or char(2). Most have an index. It's a

Re: [GENERAL] Help tuning a large table off disk and into RAM

2007-09-26 Thread Bill Moran
In response to James Williams [EMAIL PROTECTED]: I'm stuck trying to tune a big-ish postgres db and wondering if anyone has any pointers. I cannot get Postgres to make good use of plenty of available RAM and stop thrashing the disks. One main table. ~30 million rows, 20 columns all

Re: [GENERAL] Help tuning a large table off disk and into RAM

2007-09-26 Thread Alban Hertroys
James Williams wrote: The box has 4 x Opterons, 4Gb RAM five 15k rpm disks, RAID 5. We wanted fast query/lookup. We know we can get fast disk IO. RAID 5 is usually adviced against here. It's not particularly fast or safe, IIRC. Try searching the ML archives for RAID 5 ;) -- Alban Hertroys

Re: [GENERAL] Help tuning a large table off disk and into RAM

2007-09-26 Thread Jimmy Choi
:24 AM To: James Williams Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] Help tuning a large table off disk and into RAM In response to James Williams [EMAIL PROTECTED]: I'm stuck trying to tune a big-ish postgres db and wondering if anyone has any pointers. I cannot get Postgres

Re: [GENERAL] Help tuning a large table off disk and into RAM

2007-09-26 Thread Tom Lane
Bill Moran [EMAIL PROTECTED] writes: Give it enough shared_buffers and it will do that. You're estimating the size of your table @ 3G (try a pg_relation_size() on it to get an actual size) If you really want to get _all_ of it in all the time, you're probably going to need to add RAM to the

Re: [GENERAL] Help tuning a large table off disk and into RAM

2007-09-26 Thread Scott Marlowe
On 9/26/07, James Williams [EMAIL PROTECTED] wrote: The last is based mostly on the observation that another tiddly unrelated mysql db which normally runs fast, grinds to a halt when we're querying the postgres db (and cpu, memory appear to have spare capacity). Just a quick observation