Skip site navigation (1) Skip section navigation (2)

Re: Slow indexscan

From: "Mikko Partio" <mpartio(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow indexscan
Date: 2007-06-20 16:43:33
Message-ID: (view raw or flat)
Lists: pgsql-performance
On 6/20/07, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Mikko Partio" <mpartio(at)gmail(dot)com> writes:
> > Adding a new index does not speed up the query (although the planner
> decides
> > to use the index):
> Hm.  Lots of dead rows maybe?  What's your vacuuming policy?
>                         regards, tom lane

The table only gets inserts and selects, never updates or deletes so I guess
vacuuming isn't necessary. Anyways:

db=# SET default_statistics_target TO 1000;
db=# vacuum analyze verbose tbl_20070601;
INFO:  --Relation public.tbl_20070601--
INFO:  Index tbl_20070601_pkey: Pages 95012; Tuples 3715565: Deleted 0.
        CPU 8.63s/1.82u sec elapsed 367.57 sec.
INFO:  Index tbl_20070601_latlonvalidpar_index: Pages 27385; Tuples 3715565:
Deleted 0.
        CPU 1.55s/1.22u sec elapsed 23.27 sec.
INFO:  Removed 2865 tuples in 2803 pages.
        CPU 0.30s/0.20u sec elapsed 37.91 sec.
INFO:  Pages 83950: Changed 0, Empty 0; Tup 3715565: Vac 2865, Keep 0,
UnUsed 0.
        Total CPU 12.32s/3.69u sec elapsed 449.98 sec.
INFO:  Analyzing public.tbl_20070601
db=# set sort_mem to 50000;
db=# explain analyze * from tbl_20070601 where validtime between
20070602000000 and 20070602235500 and latitude=60.2744 and
longitude=26.4417and parname in ('temperature');

 Index Scan using tbl_20070601_latlonvalidpar on tbl_20070601 t1  (cost=
0.00..28.46 rows=13 width=137) (actual time=37.81..1415.06 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: 1416.53 msec
(3 rows)

I guess the sort_mem helped, or then part of the rows are in the cache
already. Should increasing sort_mem help here since there are no sorts etc?



In response to


pgsql-performance by date

Next:From: Michael GlaesemannDate: 2007-06-20 16:53:44
Subject: Re: Slow indexscan
Previous:From: Campbell, LanceDate: 2007-06-20 16:40:32
Subject: Re: Volunteer to build a configuration tool

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group