Re: effective_io_concurrency on EBS/gp2

Claudio Freire <klaussfreire@gmail.com>

From: Claudio Freire <klaussfreire@gmail.com>
To: hzzhangjiazhi <hzzhangjiazhi@corp.netease.com>
Cc: Vitaliy Garnashevich <vgarnashevich@gmail.com>, Gary Doades <gpd@gpdnet.co.uk>, Rick Otten <rottenwindfish@gmail.com>, "pgsql-performance@lists.postgresql.org" <pgsql-performance@lists.postgresql.org>
Date: 2018-02-01T18:39:07Z
Lists: pgsql-performance
On Wed, Jan 31, 2018 at 11:21 PM, hzzhangjiazhi
<hzzhangjiazhi@corp.netease.com> wrote:
> HI
>
>      I think this parameter will be usefull when the storage using RAID
> stripe , otherwise turn up this parameter is meaningless when only has one
> device。

Not at all. Especially on EBS, where keeping a relatively full queue
is necessary to get max thoughput out of the drive.

Problem is, if you're scanning a highly correlated index, the
mechanism is counterproductive. I had worked on some POC patches for
correcting that, I guess I could work something out, but it's
low-priority for me. Especially since it's actually a kernel "bug" (or
shortcoming), that could be fixed in the kernel rather than worked
around by postgres.