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: