Re: getting the most of out multi-core systems for repeated complex SELECT statements
Scott Marlowe <scott.marlowe@gmail.com>
From: Scott Marlowe <scott.marlowe@gmail.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Andy Colson <andy@squeakycode.net>, gnuoytr@rcn.com, pgsql-performance@postgresql.org
Date: 2011-02-04T04:04:09Z
Lists: pgsql-performance
On Thu, Feb 3, 2011 at 9:00 PM, Greg Smith <greg@2ndquadrant.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.