I used the between .. and in a vain attempt to improve performance!
Running with < and > improves the performance again by about 10 times.
The explain's below were ran on a test server I was using (not the live
server) where I had recreated the database in order to investigate
matters, so all the indexes were newly created anyway. The dual column
index was the key (literally).
======================================
Paul Mckay
Consultant Partner
Servicing Division
Clearwater-IT
e:paul_mckay@clearwater-it.co.uk
t:0161 877 6090
m: 07713 510946
======================================
-----Original Message-----
From: pgsql-performance-owner@postgresql.org
[mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Robert
Treat
Sent: 04 March 2003 17:02
To: Paul McKay
Cc: 'Tom Lane'; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Slow query performance on large table
On Tue, 2003-03-04 at 11:11, Paul McKay wrote:
> The results were
>
> clearview=# explain analyse
> clearview-# select assessment,time
> clearview-# from measurement
> clearview-# where assessment = 53661
> clearview-# and time between 1046184261 and 1046335461;
>
> NOTICE: QUERY PLAN:
>
> Index Scan using idx_measurement_assessment on measurement
> (cost=0.00..34668.61 rows=261 width=8) (actual
time=26128.07..220584.69
> rows=503 loops=1)
> Total runtime: 220587.06 msec
>
> EXPLAIN
>
> After adding the index kindly suggested by yourself and Tomasz I get,
>
> clearview=# explain analyse
> clearview-# select assessment,time
> clearview-# from measurement
> clearview-# where assessment = 53661
> clearview-# and time between 1046184261 and 1046335461;
> NOTICE: QUERY PLAN:
>
> Index Scan using ind_measurement_ass_time on measurement
> (cost=0.00..1026.92 rows=261 width=8) (actual time=15.37..350.46
> rows=503 loops=1)
> Total runtime: 350.82 msec
>
> EXPLAIN
>
>
> I vaguely recall doing a bit of a reorganize on this database a bit
back
> and it looks like I lost the primary Key index. No wonder it was going
> slow.
>
Maybe it's just me, but I get the feeling you need to work some regular
reindexing into your maintenance schedule. Given your query is using
between, I don't think it would use the index on the time field anyway
(and explain analyze seems to be supporting this). Rewrite it so that
you have a and time > foo and time < bar and I think you'll see a
difference. With that in mind, I think your speedier query results are
due more to having a non-bloated index freshly created than the fact
that it being a dual column index.
Robert Treat
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
