Re: effective_io_concurrency on EBS/gp2 - Mailing list pgsql-performance

From Claudio Freire
Subject Re: effective_io_concurrency on EBS/gp2
Date
Msg-id CAGTBQpZjj1ekDLyZ=RdyPhKAbLnow1ma66TDuBj=eradrgOskQ@mail.gmail.com
Whole thread Raw
In response to effective_io_concurrency on EBS/gp2  (Vitaliy Garnashevich <vgarnashevich@gmail.com>)
Responses Re: effective_io_concurrency on EBS/gp2
Re: effective_io_concurrency on EBS/gp2
List 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.


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: bad plan using nested loops
Next
From: Johan Fredriksson
Date:
Subject: SV: bad plan using nested loops