Re: BUG #14159: PostgreSQL 9.6 parallel scan consume very high mutex lock

On Thu, May 26, 2016 at 11:03 AM, 德哥 <digoal(at)126(dot)com> wrote:

> This is worker process's stack, when i test the hign parallel degree.
>
> [<ffffffffa00b8ff0>] ext4_llseek+0x60/0x110 [ext4]
> [<ffffffff81186eda>] vfs_llseek+0x3a/0x40
> [<ffffffff81188b96>] sys_lseek+0x66/0x80
> [<ffffffff8100c072>] system_call_fastpath+0x16/0x1b
> [<ffffffffffffffff>] 0xffffffffffffffff
>
>

Above call stack indicates that the file seek cost has increased on
employing high number of workers. I think the reason is that employing
more number of workers to perform parallel scan of same file doesn't work
very well read-ahead mechanism of OS. I think the best gain is possible
only when we use parallel degree which is most appropriate for the work
load, so unless you are sure that higher number of workers are required for
your workload, use system's default behaviour which is to set the
max_parallel_degree and let system decide how many workers are required.
Right now, we don't have very sophisticated way of defining how many
workers are appropriate for any workload, but I think it will work better
than directly setting parallel degree for a relation to very high number.

Note - Always keep the appropriate pg mailing list in cc for communication
which in this case is pgsql-bugs(at)postgresql(dot)org(dot)

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com