Jeff Janes wrote:
I think what I would do next is EXPLAIN (without ANALYZE) one of the
queries repeatedly, say once a second, while the other query either
runs or doesn't run repeatedly, that is the other query runs for 11
minutes (or however it takes to run), and then sleeps for 11 minutes
i
On Tue, Dec 3, 2013 at 1:24 PM, Metin Doslu wrote:
> 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 diffe
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
On Tue, Dec 3, 2013 at 10:49 AM, Metin Doslu 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.
>
Metin Doslu wrote:
> 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
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
