Re: getting the most of out multi-core systems for repeated complex SELECT statements

From: <gnuoytr(at)rcn(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: getting the most of out multi-core systems for repeated complex SELECT statements
Date: 2011-02-03 19:21:45
Message-ID: 20110203142145.BAY71855@ms14.lnh.mail.rcn.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

---- Original message ----
>Date: Thu, 3 Feb 2011 18:56:34 +0100
>From: pgsql-performance-owner(at)postgresql(dot)org (on behalf of Aljoša Mohorović <aljosa(dot)mohorovic(at)gmail(dot)com>)
>Subject: Re: [PERFORM] getting the most of out multi-core systems for repeated complex SELECT statements
>To: gnuoytr(at)rcn(dot)com
>Cc: pgsql-performance(at)postgresql(dot)org
>
>On Thu, Feb 3, 2011 at 4:57 PM, <gnuoytr(at)rcn(dot)com> wrote:
>> Time for my pet meme to wiggle out of its hole (next to Phil's, and a day later).  For PG to prosper in the future, it has to embrace the multi-core/processor/SSD machine at the query level.  It has to.  And it has to because the Big Boys already do so, to some extent, and they've realized that the BCNF schema on such machines is supremely efficient.  PG/MySql/OSEngineOfChoice will get left behind simply because the efficiency offered will be worth the price.
>
>this kind of view on what postgres community has to do can only be
>true if postgres has no intention to support "cloud environments" or
>any kind of hardware virtualization.
>while i'm sure targeting specific hardware features can greatly
>improve postgres performance it should be an option not a requirement.

Being an option is just fine. It's not there now. Asserting that the cloud meme, based on lowest cost marginal hardware, should dictate a database engine is putting the cart before the horse.

>forcing users to have specific hardware is basically telling users
>that you can forget about using postgres in amazon/rackspace cloud
>environments (or any similar environment).

Just not on cheap clouds, if they want maximal performance from the engine using BCNF schemas. Replicating COBOL/VSAM/flatfile applications in any relational database engine is merely deluding oneself.

>i'm sure that a large part of postgres community doesn't care about
>"cloud environments" (although this is only my personal impression)
>but if plan is to disable postgres usage in such environments you are
>basically loosing a large part of developers/companies targeting
>global internet consumers with their online products.
>cloud environments are currently the best platform for internet
>oriented developers/companies to start a new project or even to
>migrate from custom hardware/dedicated data center.
>
>> Much as it pains me to say it, but the MicroSoft approach to software: write to the next generation processor and force users to upgrade, will be the winning strategy for database engines.  There's just way too much to gain.
>
>it can arguably be said that because of this approach microsoft is
>losing ground in most of their businesses/strategies.

Not really. MicroSoft is losing ground for the same reason all other client/standalone applications are: such applications don't run any better on multi-core/processor machines. Add in the netbook/phone devices, and that they can't seem to make a version of windows that's markedly better than XP. Arguably MicroSoft is failing *because Office no longer requires* the next generation hardware to run right. Hmm? Linux prospers because it's a server OS, largely. Desktop may, or may not, remain relevant. Linux does make good use of such machines. MicroSoft applications? Not so much.
>
>Aljosa Mohorovic
>
>--
>Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
>To make changes to your subscription:
>http://www.postgresql.org/mailpref/pgsql-performance

Browse pgsql-performance by date

  From Date Subject
Next Message Ross J. Reedstrom 2011-02-03 19:24:42 Re: [HACKERS] Slow count(*) again...
Previous Message Mladen Gogala 2011-02-03 19:09:35 Re: [HACKERS] Slow count(*) again...