Problem with mergejoin performance - Mailing list pgsql-performance

From
Subject Problem with mergejoin performance
Date
Msg-id 000001cb5307$78955480$69bffd80$@com.pl
Whole thread Raw
Responses Re: Problem with mergejoin performance  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
I have a problem with some simple query:

select version();
    PostgreSQL 8.3.8 on i686-pc-linux-gnu, compiled by GCC gcc (GCC)
4.3.2 20081105 (Red Hat 4.3.2-7)
vacuum full bug_t1;
vacuum full bug_t2;
vacuum analyze bug_t1;
vacuum analyze bug_t2;
show default_statistics_target;
    1000
explain analyze SELECT ze.id ,rr.id FROM bug_t2 AS rr join bug_t1 AS ze ON
(ze.id=rr.id)  WHERE (ze.ids=94543);

Result is:

Merge Join  (cost=18.90..20.85 rows=1 width=8) (actual time=614.912..614.912
rows=0 loops=1)
   Merge Cond: (rr.id = ze.id)
   ->  Index Scan using bug_t2_i1 on bug_t2 rr  (cost=0.00..17893.49
rows=278417 width=4) (actual time=0.023..351.945 rows=278417 loops=1)
   ->  Sort  (cost=18.88..18.89 rows=4 width=4) (actual time=0.164..0.164
rows=1 loops=1)
         Sort Key: ze.id
         Sort Method:  quicksort  Memory: 17kB
         ->  Index Scan using bug_t1_i1 on bug_t1 ze  (cost=0.00..18.84
rows=4 width=4) (actual time=0.059..0.141 rows=4 loops=1)
               Index Cond: (ids = 94543)
 Total runtime: 615.003 ms

But after

SET enable_mergejoin=off;

result is:

Nested Loop  (cost=0.00..52.06 rows=1 width=8) (actual time=0.084..0.084
rows=0 loops=1)
   ->  Index Scan using bug_t1_i1 on bug_t1 ze  (cost=0.00..18.84 rows=4
width=4) (actual time=0.016..0.028 rows=4 loops=1)
         Index Cond: (ids = 94543)
   ->  Index Scan using bug_t2_i1 on bug_t2 rr  (cost=0.00..8.29 rows=1
width=4) (actual time=0.008..0.008 rows=0 loops=4)
         Index Cond: (rr.id = ze.id)
Total runtime: 0.154 ms


I think that problem is with estimation of total mergejoin time, why is it
so small (18.90..20.85) while estimates of subqueries (especially first) is
high (0..17893). Merging time should be high, because it needs to scan
almost all bug t2 table. Am I right?


Artur Zajac





pgsql-performance by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Slow SQL lookup due to every field being listed in SORT KEY
Next
From: Gerhard Wiesinger
Date:
Subject: Re: Major performance problem after upgrade from 8.3 to 8.4