Re: Why sequential scan when there's a supporting index? - Mailing list pgsql-novice

From Henshall, Stuart - WCP
Subject Re: Why sequential scan when there's a supporting index?
Date
Msg-id E2870D8CE1CCD311BAF50008C71EDE8E01F748B8@MAIL_EXCHANGE
Whole thread Raw
In response to Why sequential scan when there's a supporting index?  (Ron Johnson <ron.l.johnson@cox.net>)
Responses Re: Why sequential scan when there's a supporting index?  (Ron Johnson <ron.l.johnson@cox.net>)
List pgsql-novice

Try:
SELECT tx_date FROM t_lane_tx ORDER BY tx_date DESC LIMIT 1;
hth,
- Stuart

> -----Original Message-----
> From: Ron Johnson [mailto:ron.l.johnson@cox.net]
>
> Hi,
>
> As you can see, I "VACUUM VERBOSE ANALYZE" my table, describe
> the index on the table, then try to find the max() value of
> the indexed field.  However, EXPLAIN still shows that the
> query wants to sequentially scan the table.
>
> Why?
>
> TIA,
> Ron
>
> test2=# vacuum verbose analyze t_lane_tx;
> NOTICE:  --Relation t_lane_tx--
> NOTICE:  Pages 1785858: Changed 0, Empty 0; Tup 33931294: Vac
> 0, Keep 0,
> UnUsed 0.
>       Total CPU 77.03s/7.24u sec elapsed 494.00 sec.
> NOTICE:  Analyzing t_lane_tx
> VACUUM
> test2=# \d i_lane_tx_tmp
> Index "i_lane_tx_tmp"
>  Column  | Type
> ---------+------
>  tx_date | date
> btree
>
> test2=# explain select max(tx_date) from t_lane_tx;
> NOTICE:  QUERY PLAN:
>
> Aggregate  (cost=2209999.20..2209999.20 rows=1 width=4)
>   ->  Seq Scan on t_lane_tx  (cost=0.00..2125170.96 rows=33931296
> width=4)
>

pgsql-novice by date:

Previous
From: Ron Johnson
Date:
Subject: Why sequential scan when there's a supporting index?
Next
From: Ron Johnson
Date:
Subject: Re: Why sequential scan when there's a supporting index?