Why do you say to expect slow performance on this hardware? Is there
something specific about the configuration that worries you? Or, just
lots of data in the database, so the data will be on disk and not in the
cache (system or postgresql)?
What do you classify as *slow*? Obviously, he is dependent on the I/O
channel given the size of the tables. So, good indexing will be
required to help on the queries. No comments on the commit rate for
this data (I am guessing that it is slow, given the description of the
database), so that may or may not be an issue.
Depending on the type of queries, perhaps clustering will help, along
with some good partitioning indexes.
I just don't see the slow in the hardware. Of course, if he is
targeting lots of concurrent queries, better add some additional
processors, or better yet, use ERSERVER and replicate the data to a farm
of machines. [To avoid the I/O bottleneck of lots of concurrent queries
against these large tables].
I guess there are a lot of assumptions on the data's use to decide if
the hardware is adequate or not :-)
Josh Berkus wrote:
>>[linux, 700MHz athlon, 512MB RAM, 700GB 10kRPM SCSI HW RAID, postgresql 7.2]
>What kind of RAID? How many drives? Will you be updating the data
>frequently, or mostly just running reports on it?
>Unless you have a *really* good RAID array, expect slow performance on this
Charles H. Woloszynski
115 Research Drive
Bethlehem, PA 18015
tel: 610-419-2210 x400
In response to
pgsql-performance by date
|Next:||From: jasiek||Date: 2002-12-19 19:28:30|
|Subject: Re: EXISTS vs IN vs OUTER JOINS|
|Previous:||From: Josh Berkus||Date: 2002-12-19 19:15:20|
|Subject: Re: 4G row table?|