Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 1F268632400 for ; Wed, 4 Aug 2010 16:51:53 -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 56832-05 for ; Wed, 4 Aug 2010 19:51:45 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from serenity.inversion.ee (serenity.inversion.ee [194.204.33.112]) by mail.postgresql.org (Postfix) with ESMTP id 5F49B6321F9 for ; Wed, 4 Aug 2010 16:51:45 -0300 (ADT) Received: by serenity.inversion.ee (Postfix, from userid 108) id 765C9E34473; Wed, 4 Aug 2010 21:32:57 +0300 (EEST) Received: from [IPv6:::1] (localhost [127.0.0.1]) by serenity.inversion.ee (Postfix) with ESMTP id 13A91E3432C; Wed, 4 Aug 2010 21:32:57 +0300 (EEST) Subject: Re: Questions on query planner, join types, and work_mem From: Hannu Krosing To: Greg Smith Cc: Tom Lane , Robert Haas , Peter Hussey , pgsql-performance In-Reply-To: <4C59BCA8.2060603@2ndquadrant.com> 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> <4C59BCA8.2060603@2ndquadrant.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 04 Aug 2010 22:51:44 +0300 Message-ID: <1280951504.3735.93.camel@hvost> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit 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 X-Spam-Level: X-Archive-Number: 201008/64 X-Sequence-Number: 39907 On Wed, 2010-08-04 at 15:16 -0400, Greg Smith wrote: > 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, Do you mean "written to disk", or written out from shared_buffers to disk cache ? > 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. That's what I meant. Both writes to and read from the OS cache take a significant amount of time once you are not doing real disk I/O. > 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 > >