From: Mikko Partio <mpartio@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: Slow indexscan
Date: Wed, 20 Jun 2007 19:43:33 +0300
Message-ID: <2ca799770706200943l6ae9f6bfif54683e21fa33f35@mail.gmail.com> (raw)
In-Reply-To: <18952.1182355276@sss.pgh.pa.us>
References: <2ca799770706200702y1074f066s61279b67f93315d0@mail.gmail.com>
<17907.1182352197@sss.pgh.pa.us>
<2ca799770706200855w1a6b6a7cy8526b9be0ef9c97c@mail.gmail.com>
<18952.1182355276@sss.pgh.pa.us>
On 6/20/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> "Mikko Partio" <mpartio@gmail.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;
SET
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
VACUUM
db=# set sort_mem to 50000;
SET
db=# explain analyze * 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 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?
Regards
MP
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mpartio@gmail.com, tgl@sss.pgh.pa.us
Subject: Re: Slow indexscan
In-Reply-To: <2ca799770706200943l6ae9f6bfif54683e21fa33f35@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox