Re: Sun Fire T2000 and PostgreSQL 8.1.3 - Mailing list pgsql-performance

From Bruce Momjian
Subject Re: Sun Fire T2000 and PostgreSQL 8.1.3
Date
Msg-id 200604130255.k3D2tt219058@candle.pha.pa.us
Whole thread Raw
In response to Re: Sun Fire T2000 and PostgreSQL 8.1.3  ("Juan Casero \(FL FLC\)" <Juan.Casero@wholefoods.com>)
List pgsql-performance
I am thinking the most flexible solution would be to get a dual Operon
machine, and initially do both data loading and queries on the same
machine.  When the load gets too high, buy a second machine and set it
up as a Slony slave and run your queries on that, and do the data loads
on the original machine as master.

---------------------------------------------------------------------------

Juan Casero (FL FLC) wrote:
> Because I plan to develop a rather large (for us anyway) data warehouse
> with PostgreSQL.  I am looking for the right hardware that can handle
> queries on a database that might grow to over a 100 gigabytes.  Right
> now our decision support system based on postgresql 8.1.3 stores retail
> sales information for about 4 four years back *but* only as weekly
> summaries.  I want to build the system so it can handle daily sales
> transactions also.  You can imagine how many more records this will
> involve so I am looking for hardware that can give me the performance I
> need to make this project useable.  In other words parsing and loading
> the daily transaction logs for our stores is likely to take huge amounts
> of effort.  I need a machine that can complete the task in a reasonable
> amount of time.  As people start to query the database to find sales
> related reports and information I need to make sure the queries will run
> reasonably fast for them.  I have already hand optimized all of my
> queries on the current system.  But currently I only have weekly sales
> summaries.  Other divisions in our company have done a similar project
> using MS SQL Server on SMP hardware far outclassing the database server
> I currently use and they report heavy loads on the server with less than
> ideal query run times.  I am sure I can do my part to optimize the
> queries once I start this project but there is only so much you can do.
> At some point you just need more powerful hardware.  This is where I am
> at right now.  Apart from that since I will only get this one chance to
> buy a new server for data processing I need to make sure that I buy
> something that can grow over time as our needs change.  I don't want to
> buy a server only to find out later that it cannot meet our needs with
> future database projects.  I have to balance a limited budget, room for
> future performance growth, and current system requirements.  Trust me it
> isn't easy.
>
>
> Juan
>
> -----Original Message-----
> From: Josh Berkus [mailto:josh@agliodbs.com]
> Sent: Thursday, April 06, 2006 2:57 AM
> To: pgsql-performance@postgresql.org
> Cc: Juan Casero (FL FLC); Luke Lonergan
> Subject: Re: [PERFORM] Sun Fire T2000 and PostgreSQL 8.1.3
>
> Juan,
>
> > Ok that is beginning to become clear to me.  Now I need to determine
> > if this server is worth the investment for us.  Maybe it is not a
> > speed daemon but to be honest the licensing costs of an SMP aware
> > RDBMS is outside our budget.
>
> You still haven't explained why you want multi-threaded queries.  This
> is sounding like keeping up with the Joneses.
>
> --
> Josh Berkus
> Aglio Database Solutions
> San Francisco
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>

--
  Bruce Momjian   http://candle.pha.pa.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-performance by date:

Previous
From: "Jignesh K. Shah"
Date:
Subject: Re: bad performance on Solaris 10
Next
From: Tom Lane
Date:
Subject: Re: Inserts optimization?