Re: PG 7.4.3 optimizer choosing sequential scan. Why? - Mailing list pgsql-hackers

From Barry S
Subject Re: PG 7.4.3 optimizer choosing sequential scan. Why?
Date
Msg-id e-udnSr_5vFHQZzcRVn-oA@giganews.com
Whole thread Raw
Responses Re: PG 7.4.3 optimizer choosing sequential scan. Why?  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
> * 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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PITR COPY Failure (was Point in Time Recovery)
Next
From: murphy pope
Date:
Subject: Dumb question about parser vs. parse analyzer