Received: from dcave.digsys.bg (dcave.digsys.bg [192.92.129.5]) by postgresql.org (8.11.3/8.11.4) with ESMTP id g09Gc2B29842 for ; Wed, 9 Jan 2002 11:38:03 -0500 (EST) (envelope-from daniel@dcave.digsys.bg) Received: from dcave.digsys.bg (daniel@localhost.digsys.bg [127.0.0.1]) by dcave.digsys.bg (8.9.3/8.9.3) with ESMTP id SAA20821; Wed, 9 Jan 2002 18:37:50 +0200 (EET) Message-Id: <200201091637.SAA20821@dcave.digsys.bg> X-Mailer: exmh version 2.1.0 09/18/1999 To: Tom Lane cc: pgsql-hackers@postgresql.org Subject: Re: again on index usage In-reply-to: Your message of "Wed, 09 Jan 2002 10:14:05 EST." <7235.1010589245@sss.pgh.pa.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 09 Jan 2002 18:37:49 +0200 From: Daniel Kalchev X-Archive-Number: 200201/394 X-Sequence-Number: 17432 >>>Tom Lane said: > Hm. Okay, so the number-of-rows estimate is not too far off. I concur > with Hiroshi's comment: the reason the indexscan is so fast must be that > the table is clustered (physical order largely agrees with index order). > This would obviously hold if the records were entered in order by > ipdate; is that true? Yes. But... do you want me to cluster it by ipaddr for example and try it again? I understand the clustering might help with sequential scans, but why would it help with index scans? Daniel