From: | "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at> |
---|---|
To: | "Dann Corbit" <DCorbit(at)connx(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: A fairly obvious optimization? |
Date: | 2002-05-16 08:07:01 |
Message-ID: | 46C15C39FEB2C44BA555E356FBCD6FA4961DCF@m0114.s-mxs.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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).
In the meantime you can use:
select extr_stu_id from cnx_ds_sis_bill_detl_tb order by 1 desc limit 1; -- max
select extr_stu_id from cnx_ds_sis_bill_detl_tb order by 1 asc limit 1; -- min
I guess that is the reason why nobody felt really motivated to implement
this optimization. Besides these statements are more powerful, since they can fetch
other columns from this min/max row. The down side is, that this syntax varies across
db vendors, but most (all?) have a corresponding feature nowadays.
select first 1
select top 1 ...
This is actually becoming a FAQ :-)
Andreas
From | Date | Subject | |
---|---|---|---|
Next Message | D'Arcy J.M. Cain | 2002-05-16 10:11:43 | Money type |
Previous Message | Hannu Krosing | 2002-05-16 06:21:40 | Re: A fairly obvious optimization? |