Why is outer Join way quicker?

From: David Link <dlink(at)soundscan(dot)com>
To: "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Why is outer Join way quicker?
Date: 2002-04-23 16:23:34
Message-ID: 3CC58A86.9254C985@soundscan.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi.

We have found that by using an Outer Join it speeds up this query
considerably.

Why is that?

According to the explain plan the hold up has to do with a single nexted
loop and a "Materilize"? This makes no sense to me. Can some one
explain.

Thanks. -David

The difference between these two queries is the first uses an outer join
between u and t, while the second (the slower) uses a straight forward
join).

-- Query 1:
SELECT u.upc, t.title, tot.ytd, tot.rtd
FROM upc u
LEFT OUTER JOIN title t
ON t.tcode = u.tcode
LEFT OUTER JOIN total tot
ON tot.tcode = t.tcode AND tot.week = 200210 AND
tot.region='TOTAL'
WHERE u.upc LIKE '%0085392227%'
ORDER BY title ASC
LIMIT 500 OFFSET 0;

-- Query 1: Actual Time: 1 second
0.03user 0.00system 0:00.96elapsed 3%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (576major+168minor)pagefaults 0swaps

-- Query 1: QUERY PLAN:
Limit (cost=2801.10..2801.10 rows=1 width=108)
-> Sort (cost=2801.10..2801.10 rows=1 width=108)
-> Nested Loop (cost=0.00..2801.09 rows=1 width=108)
-> Nested Loop (cost=0.00..2796.06 rows=1 width=48)
-> Seq Scan on upc u (cost=0.00..2791.43 rows=1 width=24)
-> Index Scan using title_pkey on title t (cost=0.00..4.63
rows=1 width=24)
-> Index Scan using total_week_tcode_ind on total tot
(cost=0.00..5.01 rows=1 width=60)

-- =======================================
-- Query 2
explain
SELECT u.upc, t.title, tot.ytd, tot.rtd
FROM upc u,
title t left outer join total tot
ON tot.tcode = t.tcode AND tot.week = 200210 AND
tot.region='TOTAL'
WHERE t.tcode = u.tcode and u.upc LIKE '%0085392227%'
ORDER BY title ASC LIMIT 500 OFFSET 0;

-- Query 2: Actual Time: 36 SECONDS!!!
0.01user 0.02system 0:35.33elapsed 0%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+0outputs (576major+168minor)pagefaults 0swaps

Limit (cost=541352.96..541352.96 rows=1 width=108)
-> Sort (cost=541352.96..541352.96 rows=1 width=108)
-> Nested Loop (cost=0.00..541352.95 rows=1 width=108)
-> Seq Scan on upc u (cost=0.00..2791.43 rows=1 width=24)
-> Materialize (cost=537241.84..537241.84 rows=105575 width=84)
-> Nested Loop (cost=0.00..537241.84 rows=105575 width=84)
-> Seq Scan on title t (cost=0.00..6228.75 rows=105575
width=24)
-> Index Scan using total_week_tcode_ind on total tot
(cost=0.00..5.01 rows=1 width=60)

-- Output (from both Query 1 and Query 2):
upc | title | ytd | rtd
--------------+--------------------------------+--------+---------
008539222773 | CATS AND DOGS | 65240 | 1080103
008539222772 | CATS AND DOGS-2001-PS | 47683 | 480374
008539222793 | CATS & DOGS | |
008539222753 | MATRIX/MATRIX REVISITED 2-PACK | 299 | 1395
008539222783 | SWORDFISH | 27992 | 234049
008539222782 | SWORDFISH | 136727 | 987219
(6 rows)

Responses

Browse pgsql-general by date

  From Date Subject
Next Message wsheldah 2002-04-23 16:26:46 Re: Connections per second?
Previous Message Oleg Bartunov 2002-04-23 16:19:22 Re: Connections per second?