On Thu, 2 Jun 2005 06:19 am, Casey Allen Shobe wrote:
I found this response to my original post, and tried every single suggestion
in it, which has not helped:
http://archives.postgresql.org/pgsql-performance/2004-11/msg00416.php
I'm sorry to come begging for help, but this is a MAJOR
On Wednesday 01 June 2005 20:19, Casey Allen Shobe wrote:
We've seen PostgreSQL performance as a dspam database be simply stellar on
some machines with absolutely no tuning to the postgres.conf, and no
statistics target altering.
Wow. That took a phenomenally long time to post. I asked on
Casey Allen Shobe wrote:
On Wednesday 01 June 2005 20:19, Casey Allen Shobe wrote:
...
Long-term, whenever we hit the I/O limit again, it looks like we really don't
have much of a solution except to throw more hardware (mainly lots of disks
in RAID0's) at the problem. :( Fortunately, with
PostgreSQL and say to use MySQL if you want reasonable performance.
If you want MySQL performance and reliability with postgres, simply run
it with fsync deactivated ;)
I'd suggest a controller with battery backed up cache to get rid of the 1
commit = 1 seek boundary.
Makes it
real
On Mon, Jun 06, 2005 at 10:08:23AM -0500, John A Meinel wrote:
I don't know if you can do it, but it would be nice to see this be 1
RAID1 for OS, 1 RAID10 for pg_xlog,
That's probably overkill--it's a relatively small sequential-write
partition with really small writes; I don't see how
On Monday 06 June 2005 15:08, John A Meinel wrote:
Be very careful in this situation. If any disks in a RAID0 fails, the
entire raid is lost. You *really* want a RAID10. It takes more drives,
but then if anything dies you don't lose everything.
We have redundancy at the machine level using
Michael Stone wrote:
On Mon, Jun 06, 2005 at 10:08:23AM -0500, John A Meinel wrote:
I don't know if you can do it, but it would be nice to see this be 1
RAID1 for OS, 1 RAID10 for pg_xlog,
That's probably overkill--it's a relatively small sequential-write
partition with really small
On Mon, Jun 06, 2005 at 10:52:09AM -0500, John A Meinel wrote:
pg_xlog benefits from being super fast. Because it has to be fully
synced before the rest of the data can be committed. Yes they are small,
but if you can make it fast, you eliminate that overhead. It also
benefits from having it's
We've seen PostgreSQL performance as a dspam database be simply stellar on
some machines with absolutely no tuning to the postgres.conf, and no
statistics target altering.
Some months ago, I moved my domains from a crusty old generic PIII 733 to a
brand new Athlon 3000+ server that I was
