Gavin Sherry wrote: > > Gavin, is that a big win compared to just using the index and looping > > through the entries, knowing that the index matches are on the same > > page, and the heap matches are on the same page. > > Bruce, > > It would cut out the index over head. Besides at (1) (above) we would have > determined that an index scan was too expensive and we would be using a > SeqScan instead. This would just be faster, since a) we would locate the > tuples more intelligently b) we wouldn't need to scan the whole heap once > we'd found all tuples matching the scan key.
Yes, but in a clustered table, an index scan is _never_ (?) more expensive than a sequential scan, at least if the optimizer is working correctly. Index scans are slower only because they assume random heap access, but with a clustered table, there is no random heap access. The index takes to right to the spot to start. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org