| From: | Vitaliy Garnashevich <vgarnashevich(at)gmail(dot)com> |
|---|---|
| To: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
| Cc: | hzzhangjiazhi <hzzhangjiazhi(at)corp(dot)netease(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-05 11:26:43 |
| Message-ID: | 7895b3f0-0871-2b04-d3a3-3ade175e7212@gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
> I mean, that the issue is indeed affected by the order of rows in the
> table. Random heap access patterns result in sparse bitmap heap scans,
> whereas less random heap access patterns result in denser bitmap heap
> scans. Dense scans have large portions of contiguous fetches, a
> pattern that is quite adversely affected by the current prefetch
> mechanism in linux.
>
Thanks for your input.
How can I test a sparse bitmap scan? Can you think of any SQL commands
which would generate data and run such scans?
Would a bitmap scan over expression index ((aid%1000)=0) do a sparse
bitmap scan?
Regards,
Vitaliy
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Güttler | 2018-02-05 13:14:32 | OT: Performance of VM |
| Previous Message | Claudio Freire | 2018-02-05 02:27:25 | Re: effective_io_concurrency on EBS/gp2 |