Re: Slow indexscan

On 6/20/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> "Mikko Partio" <mpartio(at)gmail(dot)com> writes:
>
> > Index Scan using tbl_20070601_pkey on tbl_20070601 t1
> > (cost=0.00..365.13rows=13 width=137) (actual time=
> > 120.83..10752.64 rows=539 loops=1)
> > Index Cond: ((validtime >= 20070602000000::bigint) AND (validtime <=
> > 20070602235500::bigint) AND (latitude = 60.2744::double precision) AND
> > (longitude = 26.4417::double precision))
> > Filter: (parname = 'temperature'::character varying)
>
> You do realize that's going to scan the entire index range from
> 20070602000000 to 20070602235500?
>
> If this is a typical query you'd be better off putting the lat/long
> columns first in the index.
>
> regards, tom lane

Thanks for the reply.

Adding a new index does not speed up the query (although the planner decides
to use the index):

db=# create index tbl_20070601_latlonvalidpar_index on tbl_20070601
(latitude,longitude,validtime,parname);
CREATE INDEX

db=# explain analyze select * from tbl_20070601 where validtime between
20070602000000 and 20070602235500 and latitude=60.2744 and
longitude=26.4417and parname in ('temperature');

QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Index Scan using tbl_20070601_latlonvalidpar_index on tbl_20070601 t1
(cost=0.00..29.18 rows=13 width=137) (actual time=3471.94..31542.90 rows=539
loops=1)
Index Cond: ((latitude = 60.2744::double precision) AND (longitude =
26.4417::double precision) AND (validtime >= 20070602000000::bigint) AND
(validtime <= 20070602235500::bigint) AND (parname =
'temperature'::character varying))
Total runtime: 31544.48 msec
(3 rows)

This is a very typical query and therefore it should be made as fast as
possible. There are several tables like this rowcount ranging from 3 million
to 13 million. I have some possibilities to modify the queries as well as
the tables, but the actual table structure is hard coded.

Any other suggestions?

Regards

MP