On Wed, Apr 28, 2010 at 6:14 AM, Craig Ringer
<craig@postnewspapers.com.au> wrote:
> On 28/04/10 18:25, Scott Marlowe wrote:
>> On Wed, Apr 28, 2010 at 3:15 AM, Piotr Kublicki <Piotr.Kublicki@iop.org> wrote:
>>>
>>> Dears,
>>>
>>> Sorry to be a royal pain, but I cannot find it anywhere in the
>>> documentation: how many threads/CPU cores Postgres v. 8.4 can utilise?
>>> We're thinking about installing Postgres on a virtual machine (RedHat 5
>>> 64-bits), however not sure how many CPUs can be wisely assigned, without
>>> wasting of resources. Can Postgres utilise multi-core/multi-threaded
>>> architecture in a reasonably extent?
>>
>> Like Craig mentioned, each connection uses one core basically, and the
>> OS can use one or maybe two. But that means that on even moderately
>> busy servers 4 to 8 cores is very reasonable. On modern hardware it's
>> easy to get 6 or 8 cores pretty cheaply. 2P machines can have 12 or
>> 16 cores for pretty cheap too.
>>
>> Pgsql will get faster quickly as you increase parallel load to the
>> number of cores you have (assuming enough memory bw to keep up) and
>> slowly trail off as you add concurrent connections. If you're likely
>> to have hundreds of concurrent connections then adding more cores past
>> 8 or 16 makes a lot of sense.
>
> ... if you expect them to all be actually doing work.
>
> Often people with huge connection counts have mostly idle connections.
> In this case they really need to use a connection pooler, and limit the
> actual live connections to Pg its self to something more reasonable.
> More cores never hurts, but if your workload isn't all that high you may
> actually not need them.
I was definitely referring to active connections.