On Sun, 2008-01-06 at 11:39 +0100, Markus Schiltknecht wrote: > I think this has to do with SE not being of much use for index scans.
Hmmm. I think it fits rather neatly with BitmapIndexScans. It would be easy to apply the index condition and/or filters to see which segments are excluded and then turn off bits in the bitmap appropriately. Not fully sure about IndexScans yet. I don't think it would be worth trying to apply SE until we estimated we would return say 100 rows. It needs to be able to work without slowing down the common path. > Or > put it another way: SE is an optimization for sequential scans. For > tables where it works well, it could possibly replace the index entirely. True > Without the index, you would rely on SE to always be able to exclude > enough segments, so that the seq scan is less expensive than an index > scan with the following table lookups. It would have to be a very fat index scan for so large a table... -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
