Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id AE265632406 for ; Wed, 4 Aug 2010 16:17:08 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 42797-05 for ; Wed, 4 Aug 2010 19:17:01 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mail.postgresql.org (Postfix) with ESMTP id 1461E632346 for ; Wed, 4 Aug 2010 16:17:01 -0300 (ADT) Received: from [192.168.1.151] (static-71-179-240-8.bltmmd.fios.verizon.net [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MLkAx-1Oh0hu3yLL-000Ps8; Wed, 04 Aug 2010 21:16:58 +0200 Message-ID: <4C59BCA8.2060603@2ndquadrant.com> Date: Wed, 04 Aug 2010 15:16:56 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Hannu Krosing CC: Tom Lane , Robert Haas , Peter Hussey , pgsql-performance Subject: Re: Questions on query planner, join types, and work_mem References: <18551.1280275502@sss.pgh.pa.us> <25534.1280498632@sss.pgh.pa.us> <1280819031.14579.38.camel@hvost> <1280944268.3735.12.camel@hvost> <22961.1280944836@sss.pgh.pa.us> <1280947287.3735.56.camel@hvost> <1280948634.3735.69.camel@hvost> In-Reply-To: <1280948634.3735.69.camel@hvost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:qjWvDLg/HY2rrX+6P5YzVIxvPKjmaAOdmS+4F1HuI/G tbmSs/5zJVhV947u0XF0cwOu4Mwk9xCaskj+stBXmvH9RP53YH M+mVwVorqAa5FZ0dz8kLXAUgngvxzazaHQyPRNSAHKOmLQcNyg 9gMCmLzAQhlSyOADkhx9tiuUKc6C+LQCgCFQTP/DGvEkMOPNcU U/m4P1GOd1/7swkOeAT8QxePNpPAhd4WQ/U9a6YWt4= 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: 201008/52 X-Sequence-Number: 39895 Hannu Krosing wrote: > There was ample space for keeping the indexes in linux cache (it has 1GB > cached currently) though the system may have decided to start writing it > to disk, so I suspect that most of the time was spent copying random > index pages back and forth between shared buffers and disk cache. > Low shared_buffers settings will result in the same pages more often being written multiple times per checkpoint, particularly index pages, which is less efficient than keeping in the database cache and updating them there. This is a slightly different issue than just the overhead of copying them back and forth; by keeping them in cache, you actually reduce writes to the OS cache. What I do to quantify that is...well, the attached shows it better than I can describe; only works on 9.0 or later as it depends on a feature I added for this purpose there. It measures exactly how much buffer cache churn happened during a test, in this case creating a pgbench database. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us