X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.2]) by svr1.postgresql.org (Postfix) with ESMTP id 21DF3D1D315 for ; Wed, 18 Feb 2004 05:10:13 +0000 (GMT) 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 80249-02 for ; Wed, 18 Feb 2004 01:10:07 -0400 (AST) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by svr1.postgresql.org (Postfix) with ESMTP id 40784D1B47D for ; Wed, 18 Feb 2004 01:10:06 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.11/8.12.11) with ESMTP id i1I5A5mc020691; Wed, 18 Feb 2004 00:10:05 -0500 (EST) To: "David Witham" Cc: pgsql-sql@postgresql.org Subject: Re: Indexes and statistics In-reply-to: References: Comments: In-reply-to "David Witham" message dated "Wed, 18 Feb 2004 15:43:07 +1100" Date: Wed, 18 Feb 2004 00:10:05 -0500 Message-ID: <20690.1077081005@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at postgresql.org X-Archive-Number: 200402/241 X-Sequence-Number: 16931 "David Witham" writes: > One of the customers is quite large (8.3% of the records): Hmm. Unless your rows are quite wide, a random sampling of 8.3% of the table would be expected to visit every page of the table, probably several times. So the planner's cost estimates do not seem out of line to me; an indexscan *should* be slow. The first question to ask is why the deviation from reality. Are the rows for that customer ID likely to be physically concentrated into a limited number of physical pages? Do you have so much RAM that the whole table got swapped in, eliminating the extra I/O that the planner is expecting? regards, tom lane