Re: Parallel Select query performance and shared buffers

Looking into syncscan.c, it says in comments:

"When multiple backends run a sequential scan on the same table, we try to
keep them synchronized to reduce the overall I/O needed."

But in my workload, every process was running on a different table.

On Tue, Dec 3, 2013 at 5:56 PM, Claudio Freire <klaussfreire(at)gmail(dot)com>wrote:

> On Tue, Dec 3, 2013 at 10:49 AM, Metin Doslu <metin(at)citusdata(dot)com> wrote:
> > We have several independent tables on a multi-core machine serving Select
> > queries. These tables fit into memory; and each Select queries goes over
> one
> > table's pages sequentially. In this experiment, there are no indexes or
> > table joins.
> >
> > When we send concurrent Select queries to these tables, query performance
> > doesn't scale out with the number of CPU cores. We find that complex
> Select
> > queries scale out better than simpler ones. We also find that increasing
> the
> > block size from 8 KB to 32 KB, or increasing shared_buffers to include
> the
> > working set mitigates the problem to some extent.
> >
> > For our experiments, we chose an 8-core machine with 68 GB of memory from
> > Amazon's EC2 service. We installed PostgreSQL 9.3.1 on the instance, and
> set
> > shared_buffers to 4 GB.
>
>
> If you are certain your tables fit in RAM, you may want to disable
> synchronized sequential scans, as they will create contention between
> the threads.
>