On Wed, Jul 22, 2015 at 10:44 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> One thing I noticed that is a bit dismaying is that we don't get a lot
> of benefit from having more workers. Look at the 0.1 data. At 2
> workers, if we scaled perfectly, we would be 3x faster (since the
> master can do work too), but we are actually 2.4x faster. Each
> process is on the average 80% efficient. That's respectable. At 4
> workers, we would be 5x faster with perfect scaling; here we are 3.5x
> faster. So the third and fourth worker were about 50% efficient.
> Hmm, not as good. But then going up to 8 workers bought us basically
> nothing.
...sorry for bumping up this mail from July...
I don't think you meant to imply it, but why should we be able to
scale perfectly? Even when the table fits entirely in shared_buffers,
I would expect memory bandwidth to become the bottleneck before a
large number of workers are added. Context switching might also be
problematic.
I have almost no sense of whether this is below or above par, which is
what I'm really curious about. FWIW, I think that parallel sort will
scale somewhat better.
--
Peter Geoghegan
