Re: Parallel Select query performance and shared buffers
| От | Metin Doslu |
|---|---|
| Тема | Re: Parallel Select query performance and shared buffers |
| Дата | |
| Msg-id | CAL1dPccjD+J8SH40WajMZFrUVoxSsLUQV1zQN_3tGqOUVgs-_A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Parallel Select query performance and shared buffers (Claudio Freire <klaussfreire@gmail.com>) |
| Ответы |
Re: Parallel Select query performance and shared buffers
|
| Список | pgsql-performance |
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@gmail.com> wrote:
On Tue, Dec 3, 2013 at 10:49 AM, Metin Doslu <metin@citusdata.com> wrote:If you are certain your tables fit in RAM, you may want to disable
> 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.
synchronized sequential scans, as they will create contention between
the threads.
В списке pgsql-performance по дате отправления: