Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id A923E1337B55 for ; Mon, 11 Oct 2010 23:19:16 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 48873-09 for ; Tue, 12 Oct 2010 02:19:09 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mail.postgresql.org (Postfix) with ESMTP id 06A5A1337B53 for ; Mon, 11 Oct 2010 23:19:08 -0300 (ADT) Received: from [192.168.1.7] (static-71-179-240-8.bltmmd.fios.verizon.net [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LodLS-1OTQsF3S9K-00go08; Tue, 12 Oct 2010 04:19:06 +0200 Message-ID: <4CB3C598.2010302@2ndquadrant.com> Date: Mon, 11 Oct 2010 22:19:04 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Joshua Tolley CC: Craig Ringer , mladen.gogala@vmsinfo.com, Neil Whelchel , "pgsql-performance@postgresql.org" Subject: Re: Slow count(*) again... References: <201010091626.18636.neil.whelchel@gmail.com> <4CB11CC7.8070300@vmsinfo.com> <4CB167CA.9070109@postnewspapers.com.au> <4CB1F46E.80205@vmsinfo.com> <4CB2410C.6010603@postnewspapers.com.au> <4cb25a0e.2a978e0a.7797.33d6@mx.google.com> In-Reply-To: <4cb25a0e.2a978e0a.7797.33d6@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:NPKjDMGg1Gp5cFSppc4yg8KJaDk6ZbhxLXqMA1BrM/r mdvzKW0wT0ZMMHlvcr4zMU/s5BRKVfviwggDh3jVOGgyNYzk+T xIA5QLkKuprjmUg1qWPcRhWRjjMx04bwiBaWMHX3YdjRI1ekrm o0Hg2Lw/G0d3+0xIcLadZBN1Ce26lumbFuVW/brCp7IMGFeVYn M7UloOOVoOEYFP3zi+SBFLmAaDdwjvm4ExCmu2BXkk= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201010/121 X-Sequence-Number: 40540 Joshua Tolley wrote: > It was asserted that reading bigger chunks would help performance; a response > suggested that, at least in Linux, setting readahead on a device would > essentially do the same thing. Or that's what I got from the thread, anyway. > I'm interested to know how similar performance might be between the large > block size case and the large readahead case. Large read-ahead addresses the complaint here (bulk reads are slow) just fine, which is one reason why this whole topic isn't nearly as interesting as claimed. Larger chunk sizes in theory will do the same thing, but then you're guaranteed to be reading larger blocks than necessary in all cases. The nice thing about a good adaptive read-ahead is that it can target small blocks normally, and only kick into heavy read-ahead mode when the I/O pattern justifies it. This is a problem for the operating system to solve, and such solutions out there are already good enough that PostgreSQL has little reason to try and innovate in this area. I routinely see seq scan throughput double on Linux just by tweaking read-ahead from the tiny defaults to a sane value. -- Greg Smith, 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services and Support www.2ndQuadrant.us Author, "PostgreSQL 9.0 High Performance" Pre-ordering at: https://www.packtpub.com/postgresql-9-0-high-performance/book