On Wed, Apr 28, 2010 at 6:14 AM, Craig Ringer <craig@xxxxxxxxxxxxxxxxxxxxx> wrote: > On 28/04/10 18:25, Scott Marlowe wrote: >> On Wed, Apr 28, 2010 at 3:15 AM, Piotr Kublicki <Piotr.Kublicki@xxxxxxx> 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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
