From: Jignesh K. Shah <J.K.Shah@Sun.COM>
To: Juan Casero (FL FLC) <Juan.Casero@wholefoods.com>
Cc: Josh Berkus <josh@agliodbs.com>
Cc: pgsql-performance@postgresql.org, Luke Lonergan <llonergan@greenplum.com>
Subject: Re: Sun Fire T2000 and PostgreSQL 8.1.3
Date: Thu, 06 Apr 2006 18:13:07 -0400
Message-ID: <44359273.6020203@sun.com> (raw)
In-Reply-To: <7583B3F1891CC0429FA4A44952AA539C66FA8B@wfm-exchprd2.wfm.pvt>
References: <7583B3F1891CC0429FA4A44952AA539C66FA8B@wfm-exchprd2.wfm.pvt>
For a DSS type workload with PostgreSQL where you end up with single
long running queries on postgresql with about 100GB, you better use
something like Sun Fire V40z with those fast Ultra320 internal drives.
This might be perfect low cost complete database in a box.
Sun Fire T2000 is great for OLTP where you can end up with hundreds of
users doing quick and small lookups and T2000 can crank simple thread
executions far better than others. However when it comes to long running
queries you end up using 1/32 of the power and may not live up to your
expectations. For example consider your PostgreSQL talking to Apache
WebServer all on T2000... You can put them in separate zones if you have
different administrators for them. :-)
As for PostgreSQL on Solaris, I already have the best parameters to use
on Solaris based on my tests, the default odatasync hurts performance on
Solaris, so does checkpoint segments, others are tweaked so that they
are set for bigger databases and hence may not show much difference on
performances...
That said I will still be interested to see your app performance with
postgreSQL on Sun Fire T2000 as there are always ways of perseverence to
improve performance :-)
Regards,
Jignesh
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
>
>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: J.K.Shah@Sun.COM, Juan.Casero@wholefoods.com, josh@agliodbs.com, llonergan@greenplum.com
Subject: Re: Sun Fire T2000 and PostgreSQL 8.1.3
In-Reply-To: <44359273.6020203@sun.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox