| From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
|---|---|
| To: | hzzhangjiazhi <hzzhangjiazhi(at)corp(dot)netease(dot)com> |
| Cc: | Vitaliy Garnashevich <vgarnashevich(at)gmail(dot)com>, Gary Doades <gpd(at)gpdnet(dot)co(dot)uk>, Rick Otten <rottenwindfish(at)gmail(dot)com>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: effective_io_concurrency on EBS/gp2 |
| Date: | 2018-02-01 18:39:07 |
| Message-ID: | CAGTBQpZjj1ekDLyZ=RdyPhKAbLnow1ma66TDuBj=eradrgOskQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, Jan 31, 2018 at 11:21 PM, hzzhangjiazhi
<hzzhangjiazhi(at)corp(dot)netease(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Johan Fredriksson | 2018-02-01 20:34:24 | SV: bad plan using nested loops |
| Previous Message | Tom Lane | 2018-02-01 15:00:41 | Re: bad plan using nested loops |