Обсуждение: Re: PG 7.4.3 optimizer choosing sequential scan. Why?

Поиск
Список
Период
Сортировка

Re: PG 7.4.3 optimizer choosing sequential scan. Why?

От
Barry S
Дата:
> * 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


Re: PG 7.4.3 optimizer choosing sequential scan. Why?

От
Greg Stark
Дата:
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