From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Andy Colson <andy(at)squeakycode(dot)net>, gnuoytr(at)rcn(dot)com, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: getting the most of out multi-core systems for repeated complex SELECT statements |
Date: | 2011-02-04 04:04:09 |
Message-ID: | AANLkTi=P5Fa1rY3zH8UOjNCm-gdBpCjuStnBs8jdg1jY@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Feb 3, 2011 at 9:00 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Andy Colson wrote:
>>
>> Cpu's wont get faster, but HD's and SSD's will. To have one database
>> connection, which runs one query, run fast, it's going to need multi-core
>> support.
>
> My point was that situations where people need to run one query on one
> database connection that aren't in fact limited by disk I/O are far less
> common than people think. My troublesome database servers aren't ones with
> a single CPU at its max but wishing there were more workers, they're the
> ones that have >25% waiting for I/O. And even that crowd is still a subset,
> distinct from people who don't care about the speed of any one core, they
> need lots of connections to go at once.
The most common case where I can use > 1 core is loading data. and
pg_restore supports parallel restore threads, so that takes care of
that pretty well.
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2011-02-04 04:10:41 | Re: [HACKERS] Slow count(*) again... |
Previous Message | Greg Smith | 2011-02-04 04:00:24 | Re: getting the most of out multi-core systems for repeated complex SELECT statements |