X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id A667BD1B1CA for ; Fri, 21 May 2004 15:20:11 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024) with ESMTP id 68633-04 for ; Fri, 21 May 2004 15:19:49 -0300 (ADT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by svr1.postgresql.org (Postfix) with ESMTP id 3A975D1B232 for ; Fri, 21 May 2004 15:19:48 -0300 (ADT) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.12.9/8.12.9) with ESMTP id i4LIJlSx048765 for ; Fri, 21 May 2004 18:19:47 GMT (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.12.9/8.12.9/Submit) id i4LIAAL3047355 for pgsql-performance@postgresql.org; Fri, 21 May 2004 18:10:10 GMT From: Chris Browne X-Newsgroups: comp.databases.postgresql.performance Subject: Re: PostgreSQL caching Date: Fri, 21 May 2004 13:22:50 -0400 Organization: cbbrowne Computing Inc Lines: 41 Message-ID: <604qq9hez9.fsf@dev6.int.libertyrms.info> References: <40782517171.20040521174209@012.net.il> <40AE2174.7060107@archonet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@news.hub.org User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) Cancel-Lock: sha1:ix5Jklr8JbKHQsGinBFpEqF4W68= To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at postgresql.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200405/183 X-Sequence-Number: 7014 dev@archonet.com (Richard Huxton) writes: > If you could "pin" data in the cache it would run quicker, but at the > cost of everything else running slower. > > Suggested steps: > 1. Read the configuration/tuning guide at: > http://www.varlena.com/varlena/GeneralBits/Tidbits/index.php > 2. Post a sample query/explain analyse that runs very slowly when not > cached. > 3. If needs be, you can write a simple timed script that performs a > query. Or, the autovacuum daemon might be what you want. I don't think this case will be anywhere near so simple to resolve. I have seen this phenomenon occur when a query needs to pull a moderate number of blocks into memory to satisfy a query that involves some moderate number of rows. Let's say you need 2000 rows, which fit into 400 blocks. The first time the query runs, it needs to pull those 400 blocks off disk, which requires 400 reads of 8K of data. That can easily take a few seconds of I/O. The second time, not only are those blocks cached, they are probably cached in the buffer cache, so that the I/O overhead disappears. There's very likely no problem with the table statistics; they are leading to the right query plan, which happens to need to do 5 seconds of I/O to pull the data into memory. What is essentially required is the "prescient cacheing algorithm," where the postmaster must consult /dev/esp in order to get a prediction of what blocks it may need to refer to in the next sixty seconds. -- (format nil "~S@~S" "cbbrowne" "cbbrowne.com") http://cbbrowne.com/info/linuxdistributions.html "Normally, we don't do people's homework around here, but Venice is a very beautiful city, so I'll make a small exception." --- Robert Redelmeier compromises his principles