From: | "Ben" <reply(at)to-the-newsgroup(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Very slow query - why? |
Date: | 2004-02-02 18:20:35 |
Message-ID: | 9ad3036c946ac8d54b1ae3367e075e36@news.teranews.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 02 Feb 2004 09:53:50 -0500, Tom Lane wrote:
> Also note that the planner has gotten successively smarter about outer
> joins in each of the past several releases. Without knowing which PG
> version this is (and it ain't "PostgreSQL 4.3" as alleged in the OP's
> message...),
Sorry, SHB PostgreSQL 7.3 - my apologies...
> and without seeing EXPLAIN ANALYZE results, it's hard to speculate about
> what's going on.
Here they are. Also, just to explain, I wasn't really asking why the 12
second timing was happening, I was asking why this took several seconds rather
than coming back in a fraction of a second - since there were indexes on
everything, it seemed to me that the rows involved in both tables could be
identified more or less instantly, then combined as required, then
returned. >1 second on a 3 GHz processor is a TON of computing time, and
most operations appear to happen instantly within this particular
database. This machine is actually a dual 3 GHz machine, but I get the
impression that PostgreSQL uses one at a time for a particular job, so
it's not effectively 6 GHz. Still, it's a pretty fast machine. :)
The details:
EXPLAIN ANALYZE
SELECT a.zcustnum,trim(a.zcompany),trim(a.zfirstname),
trim(a.zlastname),trim(a.zaddr),trim(a.zaddr2),
trim(a.zcity),trim(a.zstate),trim(a.zzipcode),
trim(a.zcountry),a.zbigphone,a.zbigaltph,trim(a.zemail),
a.zanumb,trim(a.zsalu),trim(a.ztitle),a.zoptin,
b.zodr_date,b.zbadcheck,trim(b.zcomment),trim(b.zcomment2)
FROM sonaddr AS a LEFT OUTER JOIN momcust AS b
ON (a.zcustnum = b.zcustnum)
WHERE a.zcustnum=30538;
QUERY PLAN
----------
Merge Join (cost=34952.76..40696.70 rows=260923 width=464) (actual
time=1492.00..1492.55 rows=6 loops=1)
Merge Cond: ("outer".zcustnum = "inner".zcustnum) -> Index Scan using
acn_index on sonaddr a (cost=0.00..1965.45 rows=508 width=359) (actual
time=0.10..0.28 rows=6 loops=1)
Index Cond: (zcustnum = 30538)
-> Sort (cost=34952.76..35209.39 rows=102650 width=105) (actual
time=1441.52..1467.60 rows=27367 loops=1)
Sort Key: b.zcustnum
-> Seq Scan on momcust b (cost=0.00..13858.50 rows=102650
width=105) (actual time=0.03..521.36 rows=102657 loops=1)
Total runtime: 1504.42 msec
(8 rows)
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2004-02-02 18:55:11 | Re: Return Value of a Function |
Previous Message | Martín Marqués | 2004-02-02 18:10:27 | Re: I can't upgrade to PostgreSQL 7.4 in RedHat 9.0 |