Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1eievH-0001Cb-L3 for pgsql-performance@arkaria.postgresql.org; Mon, 05 Feb 2018 11:26:55 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eievF-0007eN-OA for pgsql-performance@arkaria.postgresql.org; Mon, 05 Feb 2018 11:26:53 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eievF-0007eE-HH for pgsql-performance@lists.postgresql.org; Mon, 05 Feb 2018 11:26:53 +0000 Received: from mail-yw0-x235.google.com ([2607:f8b0:4002:c05::235]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1eievC-0008Mf-Dn for pgsql-performance@lists.postgresql.org; Mon, 05 Feb 2018 11:26:53 +0000 Received: by mail-yw0-x235.google.com with SMTP id t201so18113998ywf.1 for ; Mon, 05 Feb 2018 03:26:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=ihqzA+GY28QZqL8TeF6nuIqn5eiK80fzv+Ee3f1NTOk=; b=Loqjhs01wAZMzPcPfadhaFsMUN1ie8x8rk/YjbU445xi4lCdfxfjUSEUcHmxDjLDQc /7mlueJ49T34zglJbzAMrLiJXo5C4y6qQ9vfGU7fMzCIb+d90QgBAAwK4fhoNJln6QD0 2WrPkig/u3ykTkrdCAPLVJ/Bbwuuo25d9MGJpYZgwLVSEaTrPq/m8JLYefFlak9oZZFH D8es1nGSOjIjarF1r3vED1ZUvUCuu6lAoMARX4AFQdEWnfeeKDVS0VzT7eJV4i8ZfW5S H0ZEzEBrJwjXvRG6PkKo/J/QBEU+784uzS/vYQrAX6Tv7KJnuTf0OwKSg9b7PWN2UZ/D l4jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=ihqzA+GY28QZqL8TeF6nuIqn5eiK80fzv+Ee3f1NTOk=; b=ZskPRv0yvKoYbscq/ncrYUBZ8WRyj0PRWmy6PjRv5mb97+++hJR1XffbPsCwzJ00zy 2lpeN1s+TUpkh55RR4Em9uF1RgjKE4gJYypfsaCj9VaY7iTUK7Jz9m3pvvyXP+VRTP9m 55Wk7lyxaXXRtf2++I8smVTBqd0WnONrj5nysYBlXOxIyOpskJBuke4ASaXO+oUOa2Sx EwRC4ZOjtN632iv6FRAIouFR0rJhrLl/GWKjmTE1pvem869a+XHQJooVXuzxaf33+Fzc ynpg3dVsCVajrOoN8XF6somcbplMl9sXNU7WohH6PL38Yi8KPTwLadcB9waLs1zXzeYT rEQw== X-Gm-Message-State: AKwxytcaqoddaE3t4fFS3AArU/mOTb/gKy1Enz6J9g9nOQBsBgGUcrgC TB+YTLFFQY1kQlkXsw2HByVMK5n5 X-Google-Smtp-Source: AH8x227lXvXqrdT5YFM8ZnwrcAJh0yp0enSfQBKuWUKF+9v1DHb3akdDxvxxhQfcPSThk83SaSjdgA== X-Received: by 10.129.51.150 with SMTP id z144mr32216975ywz.417.1517830007774; Mon, 05 Feb 2018 03:26:47 -0800 (PST) Received: from [192.168.1.183] ([193.93.78.27]) by smtp.gmail.com with ESMTPSA id i193sm2973426ywe.62.2018.02.05.03.26.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Feb 2018 03:26:47 -0800 (PST) Subject: Re: effective_io_concurrency on EBS/gp2 To: Claudio Freire Cc: hzzhangjiazhi , Gary Doades , Rick Otten , "pgsql-performance@lists.postgresql.org" References: <6c7a45df-f6ab-f2ce-6f84-9555864f6c86@gmail.com> <768e3a56-46ed-3dd1-8722-953a47857a35@gmail.com> <014801d39a99$d4c32930$7e497b90$@gpdnet.co.uk> <8fb758a1-d7fa-4dcc-fb5b-07a992ae6a32@gmail.com> <534b557c-3658-6d0f-2330-34a78da57e2f@gmail.com> <9122FC8B-2129-4E10-807F-F9F34117A156@corp.netease.com> <85a21d95-a776-4c1c-3223-5568864df3f3@gmail.com> From: Vitaliy Garnashevich Message-ID: <7895b3f0-0871-2b04-d3a3-3ade175e7212@gmail.com> Date: Mon, 5 Feb 2018 13:26:43 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > 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