Re: A fairly obvious optimization?

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