Re: effective_io_concurrency on EBS/gp2
От | Claudio Freire |
---|---|
Тема | Re: effective_io_concurrency on EBS/gp2 |
Дата | |
Msg-id | CAGTBQpaOsC4=hwtO-ZkE9XVuUS2DqfiLw3-Zf_tjj1CfT49fjw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: effective_io_concurrency on EBS/gp2 (Vitaliy Garnashevich <vgarnashevich@gmail.com>) |
Ответы |
Re: effective_io_concurrency on EBS/gp2
|
Список | 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 по дате отправления: