Received: from p2272.nsk.ne.jp (p2272.nsk.ne.jp [210.145.18.145]) by postgresql.org (8.11.3/8.11.4) with ESMTP id g0GJuGV96564 for ; Wed, 16 Jan 2002 14:56:16 -0500 (EST) (envelope-from Inoue@tpf.co.jp) Received: from mcadnote1 (ppm105.noc.fukui.nsk.ne.jp [61.198.95.5]) by p2272.nsk.ne.jp (8.9.3/3.7W-20000722) with SMTP id EAA11784; Thu, 17 Jan 2002 04:55:46 +0900 (JST) From: "Hiroshi Inoue" To: "Daniel Kalchev" Cc: "pgsql-hackers" Subject: Re: again on index usage Date: Thu, 17 Jan 2002 04:55:46 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200201161112.NAA07690@dcave.digsys.bg> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-Archive-Number: 200201/663 X-Sequence-Number: 17679 > -----Original Message----- > From: Daniel Kalchev [mailto:daniel@digsys.bg] > > Well, we already played around this by first creating new table > ordered by > random(). This seem to have little meaing if there's only one ipdate value which satisfies the WHERE clause and the index order matches the physical order of heap tuples. I tried a very simple test case. I have a table which has 100000 tuples and made a index on a column whose value is always ''(i.e the same value). Different from my expectation CREATE INDEX doesn't seem to preserve the physical(input) order. However it seems sufficiently ordered and probably we could expect the scan using the index is as fast as sequential scan. The result(distribution of corrsponding CTIDs) is as follows. (3448, 17) (3542, 26) -- (5172, 24) consecutive 94539 tuples (3542, 25) -- (3448, 18) consecutive 5460 tuples regards, Hiroshi Inoue