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.