Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 4270B9F9871 for ; Sun, 19 Aug 2007 21:37:12 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 25058-07 for ; Sun, 19 Aug 2007 21:37:08 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.229]) by postgresql.org (Postfix) with ESMTP id B54B69F985C for ; Sun, 19 Aug 2007 21:37:08 -0300 (ADT) Received: by wr-out-0506.google.com with SMTP id 68so881529wri for ; Sun, 19 Aug 2007 17:37:07 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=fR2717+hamNOUa5IHX0UcaBTGwT6RkVcohGP9aMRnQzgEKRRGMf2zVZw3NZlIiZ3u7C45OLAFCyffZEJvr6bfMsHVNd1wLX9EPUvYMV6UdpHH68S/P2nf/cHle9HQacwGbWxTuqYYgoba9+WP/6YH5Df9APGfI3fWe8ITfbMFJc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=T7HzkyTzGObp1HDdoWXtxdZLjZHruMbKKgT9SuoNs38otPodAtx2H+T5khN3SmWF7jwe3Q9o/EUMJ2qAVI2qIN5BViO3BZ1xDFAkq0cgQkco82RdgHkIitR91s6iaBpmeIhtRVyYc71JEEXgStpBDTKmSFXK6NXS7SDhY1g0cPg= Received: by 10.90.25.3 with SMTP id 3mr8437186agy.1187570227215; Sun, 19 Aug 2007 17:37:07 -0700 (PDT) Received: by 10.64.199.3 with HTTP; Sun, 19 Aug 2007 17:37:07 -0700 (PDT) Message-ID: <5a0a9d6f0708191737l189ea68eh80f4d1fcb4b71ae0@mail.gmail.com> Date: Sun, 19 Aug 2007 17:37:07 -0700 From: "Andrew Hammond" To: "Luke Lonergan" Subject: Re: [pgsql-jobs] Looking for database hosting Cc: "Niklas Saers" , pgsql-performance@postgresql.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_83168_13551783.1187570227150" References: X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200708/207 X-Sequence-Number: 26337 ------=_Part_83168_13551783.1187570227150 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 8/19/07, Luke Lonergan 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:andrew.george.hammond@gmail.com > ] > Sent: Sunday, August 19, 2007 03:49 PM Eastern Standard Time > To: Niklas Saers > Cc: pgsql-jobs@postgresql.org; 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 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 > > > > ------=_Part_83168_13551783.1187570227150 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 8/19/07, Luke Lonergan <LLonergan@greenplum.com> 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:andrew.george.hammond@gmail.com]
Sent:   Sunday, August 19, 2007 03:49 PM Eastern Standard Time
To:     Niklas Saers
Cc:     pgsql-jobs@postgresql.org; 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 <niklassaers@gmail.com> 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
>


------=_Part_83168_13551783.1187570227150--