William Yu wrote:
> My situation is this. We have a semi-production server where we
> pre-process data and then upload the finished data to our production
> servers. We need the fastest possible write performance. Having the DB
> go corrupt due to power loss/OS crash is acceptable because we can
> always restore from last night and re-run everything that was done since
> I already have fsync off. Short of buying more hardware -- which I will
> probably do anyways once I figure out whether I need more CPU, memory or
> disk -- what else can I do to max out the speed? Operation mix is about
> 50% select, 40% insert, 10% update.
In line with what Tom Lane said, you may want to look at the various
memory databases available (I'm not familiar with any one to recommend,
though) If you can fit the whole database in RAM, that would work
great, if not, you may be able to split the DB up and put the most
used tables just in the memory database.
I have also seen a number tutorials on how to put a database on a
RAM disk. This helps, but it's still not as fast as a database server
that's designed to keep all its data in RAM.
In response to
pgsql-performance by date
|Next:||From: Rajesh Kumar Mallah||Date: 2003-11-24 17:13:59|
|Subject: VACUUM problems with 7.4|
|Previous:||From: Nick Barr||Date: 2003-11-24 11:24:47|
|Subject: Re: pg_autoconfig.pl|