On Sun, 23 Jun 2002 17:16:09 EDT, the world broke into rejoicing as
Bruce Momjian <[EMAIL PROTECTED]> said:
> FAQ updated in section 4.8: My queries are slow or don't make use of the
> indexes. Why?
>
> is returned. In fact, though MAX() and MIN() don't use indexes,
> it is possible
FAQ updated in section 4.8: My queries are slow or don't make use of the
indexes. Why?
is returned. In fact, though MAX() and MIN() don't use indexes,
it is possible to retrieve such values using an index with ORDER BY
and LIMIT:
SELECT col
FROM tab
ORDER BY col
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, i
> 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
Considering this schema:
-- Table: cnx_ds_sis_bill_detl_tb
CREATE TABLE "cnx_ds_sis_bill_detl_tb" (
"extr_stu_id" char(10),
"term_cyt" char(5),
"subcode" char(5),
"tran_seq" int2,
"crc" int8,
CONSTRAINT "pk_cnx_ds_sis_bill_detl_tb" UNIQUE ("extr_stu_id",
"term_cyt", "subcode", "t
