Re: PG 7.4.3 optimizer choosing sequential scan. Why?
* 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
Import Notes
Reference msg id not found: 4nkMc.131Ni4.20@news04.bloor.is.net.cable.rogers.com
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