X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 4DE385280B for ; Mon, 13 Jun 2005 09:59:47 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 11465-04 for ; Mon, 13 Jun 2005 12:59:37 +0000 (GMT) Received: from oismail.com (unknown [38.117.22.100]) by svr1.postgresql.org (Postfix) with ESMTP id 649A552823 for ; Mon, 13 Jun 2005 09:59:36 -0300 (ADT) Received: from [192.168.8.103] ([213.173.234.215]) (authenticated bits=0) by oismail.com (8.12.11/8.12.11) with ESMTP id j5DCxiaO009802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 13 Jun 2005 08:59:46 -0400 Message-ID: <42AD844F.3070700@oismail.com> Date: Mon, 13 Jun 2005 15:04:15 +0200 From: Jona User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: How to enhance the chance that data is in disk cache References: <579bc853ef3957c736c2773f13c444f7@implements.be> <42ACF2DD.8090409@paradise.net.nz> <42AD49BF.7050706@paradise.net.nz> In-Reply-To: <42AD49BF.7050706@paradise.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.133 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO, NORMAL_HTTP_TO_IP X-Spam-Level: X-Archive-Number: 200506/283 X-Sequence-Number: 12920 Hi there I have a query (please refer to http://213.173.234.215:8080/get_content_plan.htm for the query as well as query plan) that is slow when it's run the first time and fast(ish) on all successive runs within a reasonable time period. That is, if the query is not run for like 30 min, execution time returns to the initial time. This leads me to suspect that when the query is first run, all used data have to be fetched from the disk where as once it has been run all data is available in the OS's disk cache. Comparing the execution times we're talking roughly a factor 35 in time difference, thus optimization would be handy. Is there anway to either enhance the chance that the data can be found in the disk cache or allowing the database to fetch the data faster? Is this what the CLUSTER command is for, if so, which tables would I need to cluster? Or is my only option to de-normalize the table structure around this query to speed it up? Furthermore, it seems the database spends the majority of its time in the loop marked with italic in the initial plan, any idea what it spends its time on there? Database is PG 7.3.9 on RH ES 3.0, with Dual XEON 1.9GHz processors and 2GB of RAM. effective_cache_size = 100k shared_buffers = 14k random_page_cost = 3 default_statistics_target = 50 VACUUM ANALYZE runs every few hours, so statistics should be up to date. Appreciate any input here. Cheers Jona