> * The table contains one index: P1_NRN_ROAD_V (v, sobjid) (The index
> includes the column sobjid because the query projects this col, and its
> inclusion in the index allows it to be serviced without accessing the
> underlying table)
> Now, for the queries:
> 
> QUERY 2: select sobjid from p1_nrn_road where v = 1
> 
> The plan is "Seq Scan on p1_nrn_road (cost=0.00..22158.54 rows=2 width=8)"
> 
> 

That is puzzling. However, if you are only going to make a selection
criteria for 'v', why the multi-column index? Setting an index on only
'v' should produce better results...

-Barry

Fri, 23 Jul 2004 22:51:54 -0500
Barry S <barry@nospam.4.me.thx.com>
Re: PG 7.4.3 optimizer choosing sequential scan. Why?

Barry S <barry@nospam.4.me.thx.com> writes:

> > * The table contains one index: P1_NRN_ROAD_V (v, sobjid) (The index
> > includes the column sobjid because the query projects this col, and its
> > inclusion in the index allows it to be serviced without accessing the
> > underlying table)

(Unlike Oracle) Postgres *always* has to access the underlying table.

-- 
greg


26 Jul 2004 02:12:00 -0400
Greg Stark <gsstark@mit.edu>
Re: PG 7.4.3 optimizer choosing sequential scan. Why?