Received: from sss.pgh.pa.us ([192.204.191.242]) by postgresql.org (8.11.3/8.11.4) with ESMTP id g0AF7jB25274 for ; Thu, 10 Jan 2002 10:07:46 -0500 (EST) (envelope-from tgl@sss.pgh.pa.us) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.11.4/8.11.4) with ESMTP id g0AF7Cg20481; Thu, 10 Jan 2002 10:07:12 -0500 (EST) To: "Zeugswetter Andreas SB SD" cc: "Daniel Kalchev" , pgsql-hackers@postgresql.org Subject: Re: again on index usage In-reply-to: <46C15C39FEB2C44BA555E356FBCD6FA41EB499@m0114.s-mxs.net> References: <46C15C39FEB2C44BA555E356FBCD6FA41EB499@m0114.s-mxs.net> Comments: In-reply-to "Zeugswetter Andreas SB SD" message dated "Thu, 10 Jan 2002 11:55:20 +0100" Date: Thu, 10 Jan 2002 10:07:11 -0500 Message-ID: <20478.1010675231@sss.pgh.pa.us> From: Tom Lane X-Archive-Number: 200201/441 X-Sequence-Number: 17470 "Zeugswetter Andreas SB SD" writes: > I cannot really see how 284 rows can have an estimated index cost of 100506 ? The estimated number of indexscanned rows is more like 50k. The number you are looking at includes the estimated selectivity of the non-indexable WHERE clauses, too. > What is actually estimated wrong here seems to be the estimated > effective cache size, and thus the cache ratio of page fetches. Good point, but I think the estimates are only marginally sensitive to estimated cache size (if they're not, we have a problem, considering how poorly we can estimate the kernel's disk buffer size). It would be interesting for Daniel to try a few different settings of effective_cache_size and see how much the EXPLAIN costs change. regards, tom lane