From: | "Strong, David" <david(dot)strong(at)unisys(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Simon Riggs" <simon(at)2ndquadrant(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Straightforward changes for increased SMP scalability |
Date: | 2007-07-16 16:52:27 |
Message-ID: | B6419AF36AC8524082E1BC17DA2506E803CE92DF@USMV-EXCH2.na.uis.unisys.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> I'm happy to run some benchmarks to show the improvements with
various
>> NUM_BUFFER_PARTITIONS settings. However, I want to make sure that
this
>> is going to be useful. I can run 16 (base), 32, 64, 128 etc. type
>> increments, but I'm more concerned about the number of cores to use.
Do
>> you have a suggestion for that? I can run with 1 to 32 cores. I had
>> planned to run a number of tests at 8 cores, but I can adjust to what
?> makes sense for the community.
>
>Presumably the answers will be different. I'd sort of like to see
>several different curves for different numbers of processors, so we
>can evaluate reasonably fairly.
>
> regards, tom lane
Tom,
Correct. This is a scalability patch rather than a performance patch,
although each aspect is related. I would expect the gain to be better as
more cores and users are added.
I can run some tests along the following lines:
1. NUM_BUFFER_PARITIONS sizes for 16, 32, 64, 128, 256, 512, 1024, 2048.
2. Cores set at 1, 2, 4, 8, 16, 24 and 32.
Does anyone have any comments or suggestions?
David
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2007-07-16 17:14:43 | Re: Straightforward changes for increased SMP scalability |
Previous Message | Tom Lane | 2007-07-16 16:45:32 | Re: Straightforward changes for increased SMP scalability |