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 <klaussfre...@gmail.com>wrote: > On Tue, Dec 3, 2013 at 10:49 AM, Metin Doslu <me...@citusdata.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. >
