On Wed, 2002-05-15 at 23:23, Dann Corbit wrote: > The select(min) and select(max) took as long as the table scan to find > the count. It seems logical if a btree type index is available (such > as pk_cnx_ds_sis_bill_detl_tb) where the most significant bit of the > index is the column requested, it should be little more than a seek > first or seek last in the btree. Obviously, it won't work with a hashed > index (which is neither here nor there).
The problem is postgres' extensibility -there is no hard-wired connection between max() and b-tree indexes - you can define an aggregate max() that returns something completely diffrent, say the longest string length or the "best" optimisation techniqe which may or may not be able to use an index. ------------ Hannu ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
