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.