Just to make things more clear I ran EXPLAIN ANALYZE on the slow query.
I got
Merge Full Join (cost=62.33..73.36 rows=1000 width=19) (actual
time=39.205..8521.644 rows=272 loops=1)
Merge Cond: ("outer".pkey = "inner".d1)
-> Index Scan using mutualfd_weekday_qbid_pkey_idx on
mutualfd_weekday_qbid (cost=0.00..6.01 rows=1 width=19) (actual
time=34.579..8510.801 rows=253 loops=1)
Index Cond: ((pkey >= '2005-12-15'::date) AND (pkey <=
'2006-12-15'::date))
Filter: (cusip = '92193920'::text)
-> Sort (cost=62.33..64.83 rows=1000 width=4) (actual
time=4.604..5.674 rows=262 loops=1)
Sort Key: d1.d1
-> Function Scan on "getDateRange" d1 (cost=0.00..12.50
rows=1000 width=4) (actual time=2.591..3.591 rows=262 loops=1)
Total runtime: 8522.894 ms
(9 rows)
It looks like this line:
"-> Index Scan using mutualfd_weekday_qbid_pkey_idx on
mutualfd_weekday_qbid (cost=0.00..6.01 rows=1 width=19) (actual
time=34.579..8510.801 rows=253 loops=1)"
is the problem. As I understand it is using the index but it is low as
dirt. Hopefully, the -z will fix this. I also ran the same query but
with earlier dates in the table and the query ran much faster.
Merge Full Join (cost=3492.48..3505.60 rows=1034 width=19) (actual
time=7.605..12.851 rows=273 loops=1)
Merge Cond: ("outer".d1 = "inner".pkey)
-> Sort (cost=62.33..64.83 rows=1000 width=4) (actual
time=4.586..5.530 rows=263 loops=1)
Sort Key: d1.d1
-> Function Scan on "getDateRange" d1 (cost=0.00..12.50
rows=1000 width=4) (actual time=2.493..3.515 rows=263 loops=1)
-> Sort (cost=3430.15..3432.74 rows=1034 width=19) (actual
time=2.998..3.971 rows=263 loops=1)
Sort Key: mutualfd_weekday_qbid.pkey
-> Index Scan using mutualfd_weekday_qbid_pkey on
mutualfd_weekday_qbid (cost=0.00..3378.38 rows=1034 width=19) (actual
time=0.075..1.843 rows=263 loops=1)
Index Cond: ((cusip = '92193920'::text) AND (pkey >=
'1999-12-15'::date) AND (pkey <= '2000-12-15'::date))
Total runtime: 13.935 ms
(10 rows)
In this case it only took 13.935ms as compared to 8522.894 ms for the
newer data.
Benjamin
Shoaib Mir wrote:
....adding to the last email, for now try the work_mem but you should
be adding ANALYZE along with the VACUUM (with a cron job I guess) you
do regularly.
------------
Shoaib Mir
EntperpriseDB ( www.enterprisedb.com <http://www.enterprisedb.com>)
On 12/24/06, *Shoaib Mir* <shoaibmir@xxxxxxxxx
<mailto:shoaibmir@xxxxxxxxx>> wrote:
Try increasing the work_mem first to see the change, that might help.
-------------
Shoaib Mir
EnterpriseDB ( www.enterprisedb.com <http://www.enterprisedb.com>)
On 12/24/06, *Benjamin Arai* <benjamin@xxxxxxxxxxxx
<mailto:benjamin@xxxxxxxxxxxx>> wrote:
I have been running pieces of my PL function by hand and I
have found
that the following queries work by themselves taking less than
a second
to execute.
getDateRange"('12/1/2005','12/1/2006') <- simply generates a
date
list. Doesn't even access a table
SELECT * FROM mutualfd_weekday_qbid WHERE cusip='92193920'
AND pkey >=
'12/15/2005' AND pkey <= '12/15/2006';
But when combined as below it takes 10 seconds to execute.
SELECT d1 as date, d2.data as data FROM
"getDateRange"('12/1/2005','12/1/2006') d1 FULL OUTER JOIN
(SELECT *
FROM mutualfd_weekday_qbid WHERE cusip='92193920' AND pkey >=
'12/15/2005' AND pkey <= '12/15/2006') d2 ON d1=d2.pkey;
Do I need to increase the work_mem or is this possible still a
ANALYZE
issue?
Benjamin
---------------------------(end of
broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
<http://www.postgresql.org/about/donate>
