Re: effective_io_concurrency on EBS/gp2

Claudio Freire <klaussfreire@gmail.com>

From: Claudio Freire <klaussfreire@gmail.com>
To: Vitaliy Garnashevich <vgarnashevich@gmail.com>
Cc: hzzhangjiazhi <hzzhangjiazhi@corp.netease.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-05T20:14:53Z
Lists: pgsql-performance
On Mon, Feb 5, 2018 at 8:26 AM, Vitaliy Garnashevich
<vgarnashevich@gmail.com> wrote:
>> 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?

If you have a minimally correlated index (ie: totally random order),
and suppose you have N tuples per page, you need to select less (much
less) than 1/Nth of the table.