On Fri, Feb 20, 2009 at 09:22:58AM -0800, Joshua D. Drake wrote: > On Fri, 2009-02-20 at 09:33 -0500, Andrew Dunstan wrote: > > > The short answer is that we don't know yet. There is anecdotal evidence > > that the number of CPUs on the server is a good place to start, but we > > should be honest enough to say that this is a new feature and we are > > still gathering information about its performance. If you want to give > > some advice, then I think the best advice is to try a variety of > > settings to see what works best for you, and if you have a good set of > > figures report it back to us. > > There has been some fairly heavy testing and research that caused the > patch in the first place. The thread is here: > > http://archives.postgresql.org/pgsql-hackers/2008-02/msg00695.php > > It is a long thread. The end was result was the fastest restore time for > 220G was performed with 24 threads with an 8 core box. It came in at 3.5 > hours. > > http://archives.postgresql.org/pgsql-hackers/2008-02/msg01092.php > > It is important to point out that this was a machine with 50 spindles. > Which is where your bottleneck is going to be immediately after solving > the CPU bound nature of the problem. > > So although the CPU question is easily answered, the IO is not. IO is > extremely variable in its performance. > > Sincerely, > > Joshua D. Drake > I also ran some tests against a more modest system that was still showing a performance improvement at (number-of-cores * 2):
http://archives.postgresql.org/pgsql-hackers/2008-11/msg01399.php I think that a good starting point for any use should be the number of cores given these two data points. Cheers, Ken -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
