[oclug]PostgreSQL Hardware

[Brad Barnett]

On Sat, 26 Oct 2002 12:04:17 -0400
Rod Giffin <rod at giffinscientific.com> wrote:

> On Friday 25 October 2002 21:40, Timothy Brier wrote:
> So let me throw in one new question to
> > the mix, I have found that PostgreSQL is very fast with the fsync()
> > turned off.  (As the manuals say it will be)  What is the opinion of
> > having this off when you have file systems like ext3 available?  Is
> > tar or cpio a good way to do a complete backup?
> 
> It depends on whether or not your application can be down for long
> enough to complete a manual backup.  You can also do hardware mirroring,
> and back up the mirror drive.  One of the nice things about allowing the
> database to back up itself is that in the event of data corruption, you
> can rebuild only part of the database rather than the entire table set. 
> That is a little harder to do from a tarball.
> 
> I'm sorry Timothy, I don't agree with the sentement expressed by
> everyone else here so far with regard to your server issues.  You are
> not talking about a really serious load there.  600,000 new
> records/month is something like 1.04 new records/second over the course
> of an 8 hour day.  Your web server log file would be growing faster than
> that.  In fact, from a system engineering perspective, all that number
> should tell you is how much disk space you're going to need.  It doesn't
> say anything about the load on the server.
> 
> Rod.


Actually Rod, no one was responding to his statement about the 600000
records per month _created_.  He didn't post that until _after_ most
people responded to his initial statement.  I'm still getting email
messages in a weird order too, so I feel for ya ;)

People were responding to his initial query about 700 clients connected at
once, making queries that could be as high as 60k-70k records each.  He
didn't specify the length of these records either.

This also doesn't specify the frequency of the queries or the consistency
of them.  You really shouldn't base your response above on the amount of
queries that may be written alone.  Load is also effected by read as well
as write queries.

Especially when the worst case scenario for the above is 700 people
reading at once, all doing queries of 70k records each, with some writes
thrown in.  Since we don't know precisely what this is to be used for, it
is entirely possible that the specific application has a consistent load.

Anyhow, many of the previous posts were more about database optimization,
instead of hardware.