Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id BEC0FB5DBCA for ; Sun, 15 May 2011 15:20:43 -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 86970-01 for ; Sun, 15 May 2011 18:20:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp-1.01.com (smtp-1.01.com [38.102.63.180]) by mail.postgresql.org (Postfix) with ESMTP id CAC7AB5DC26 for ; Sun, 15 May 2011 15:20:07 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp-1.01.com (Postfix) with ESMTP id 36358E320F for ; Sun, 15 May 2011 13:20:07 -0500 (CDT) Received: from smtp-1.01.com ([127.0.0.1]) by localhost (smtp-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5nCfa1CppWX for ; Sun, 15 May 2011 13:20:07 -0500 (CDT) Received: by smtp-1.01.com (Postfix, from userid 99) id 12D94E3208; Sun, 15 May 2011 13:20:07 -0500 (CDT) Received: from Sidney-Stratton.local (70-36-197-225.dsl.dynamic.sonic.net [70.36.197.225]) by smtp-1.01.com (Postfix) with ESMTPSA id AADF6E31D1 for ; Sun, 15 May 2011 13:20:06 -0500 (CDT) Message-ID: <4DD0195A.9040305@agliodbs.com> Date: Sun, 15 May 2011 11:20:10 -0700 From: Josh Berkus Organization: PostgreSQL Experts Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: reducing random_page_cost from 4 to 2 to force index scan References: <4DB6F4BB020000250003CEB9@gw.wicourts.gov> <2823.1305314437@sss.pgh.pa.us> <4DCD90F5.2010501@agliodbs.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 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: 201105/222 X-Sequence-Number: 43731 Stuart, > I think random_page_cost causes problems because I need to combine > disk random access time, which I can measure, with a guesstimate of > the disk cache hit rate. See, that's wrong. Disk cache hit rate is what effective_cache_size (ECS) is for. Really, there's several factors which should be going into the planner's estimates to determine a probability of a table being cached: * ratio between total database size and ECS * ratio between table size and ECS * ratio between index size and ECS * whether the table is "hot" or not * whether the index is "hot" or not The last two statistics are critically important for good estimation, and they are not things we currently collect. By "hot" I mean: is this a relation which is accessed several times per minute/hour and is thus likely to be in the cache when we need it? Currently, we have no way of knowing that. Without "hot" statistics, we're left with guessing based on size, which results in bad plans for small tables in large databases which are accessed infrequently. Mind you, for large tables it would be even better to go beyond that and actually have some knowledge of which disk pages might be in cache. However, I think that's beyond feasibility for current software/OSes. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com