On 8/19/07, Luke Lonergan <[EMAIL PROTECTED]> wrote: > > Andrew, > > I'd say that commodity systems are the fastest with postgres - many have > seen big slowdowns with high end servers. 'Several orders of magnitude' is > not possible by just changing the HW, >
Going from one or two SATA disks to a SAN farm ought to achieve orders of magnitude in improvement. And cost. Going from 2GB of memory up to 16 or 32GB can make significant changes as well. However I agree with you that intelligence at the application layer such that you can take advantage of a parallel approach is a superior solution both in terms of overall effectiveness and cost effectiveness. you've got a SW problem to solve first. We have done 100+ times faster than > both Postgres and popular (even gridded) commercial DBMS using an > intrinsically parallel SW approach. > That is both cool and unsurprising at the same time. One of the major challenges I've seen in practice is that small companies don't generally start off with a db design that's capable of a parallel approach. With success and growth, there comes a point where a massive re-design is needed. Companies that recognize this, make the investment and take the risk are rare. If the objective is OLAP / DSS there's no substitute for a parallel DB that > does query and load / transform using all the CPUs and IO channels > simultaneously. This role is best met from a value standpoint by clustering > commodity systems. > > For OLTP, we need better SMP and DML algorithmic optimizations for > concurrency, at which point big SMP machines work. Right now you can buy a > 32 CPU commodity (opteron) machine from SUN (X4600) for about $60K loaded. > WRT hosting, we've done a bit of it on GPDB systems, but we're not making it > a focus area. Instead, we do subscription pricing by the amount of data > used and recommend / help get systems set up. > > - Luke > > Msg is shrt cuz m on ma treo > > > -----Original Message----- > From: Andrew Hammond [mailto:[EMAIL PROTECTED]<[EMAIL PROTECTED]> > ] > Sent: Sunday, August 19, 2007 03:49 PM Eastern Standard Time > To: Niklas Saers > Cc: [EMAIL PROTECTED]; pgsql-performance@postgresql.org > Subject: Re: [PERFORM] [pgsql-jobs] Looking for database hosting > > Nik, you may be underestimating just how much performance can be obtained > from a single database server. For example, an IBM p595 server connected > to > an array of ds8300 storage devices could reasonably be expected to provide > several orders of magnitude more performance when compared to commodity > hardware. In commodity space (albeit, just barely), a 16 core opteron > running (the admittedly yet-to-be-released) FreeBSD 7, and a suitably > provisioned SAN should also enormously outperform a beige-box solution, > and > at a fraction of the cost. If it's performance you care about then the > pgsql-performance list (which I have cc'd) is the place to talk about it. > > I realize this doesn't address your desire to get out of database server > administration. I am not aware of any company which provides database > hosting, further I'm not entirely convinced that's a viable business > solution. The technical issues (security, latency and reliability are the > ones that immediately come to mind) associated with a hosted database > server > solution suggest to me that this would not be economically viable. The > business issues around out-sourcing a critical, if not central component > of > your architecture seem, at least to me, to be insurmountable. > > Andrew > > > On 8/19/07, Niklas Saers <[EMAIL PROTECTED]> wrote: > > > > Hi, > > the company I'm doing work for is expecting a 20 times increase in > > data and seeks a 10 times increase in performance. Having pushed our > > database server to the limit daily for the past few months we have > > decided we'd prefer to be database users rather than database server > > admins. :-) > > > > Are you or can you recommend a database hosting company that is good > > for clients that require more power than what a single database > > server can offer? > > > > Cheers > > > > Nik > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 9: In versions below 8.0, the planner will ignore your desire to > > choose an index scan if your joining column's datatypes do not > > match > > > >
