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 CAGTBQpaOsC4=hwtO-ZkE9XVuUS2DqfiLw3-Zf_tjj1CfT49fjw@mail.gmail.com
Whole thread Raw
In response to Re: effective_io_concurrency on EBS/gp2  (Vitaliy Garnashevich <vgarnashevich@gmail.com>)
Responses Re: effective_io_concurrency on EBS/gp2
List 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.


pgsql-performance by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: postgresql 10.1 wrong plan in when using partitions bug
Next
From: Thomas Güttler
Date:
Subject: Details after Load Peak was: OT: Performance of VM