From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Dmitry Potapov" <fortune(dot)fish(at)gmail(dot)com> |
Cc: | "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: planner chooses unoptimal plan on joins with complex key |
Date: | 2008-01-25 02:27:01 |
Message-ID: | 21624.1201228021@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
"Dmitry Potapov" <fortune(dot)fish(at)gmail(dot)com> writes:
> Sorry, it was just EXPLAIN. I can't run EXPLAIN ANALYZE on that
> (production) server, so I uploaded 3days old backup to a spare box and
> here's what I've got:
> -> Merge Join (cost=0.00..4955790.28 rows=1 width=59)
> (actual time=0.048..4575782.472 rows=30805113 loops=1)
> Merge Cond: ((t1.m1 = t2.m1) AND (t1.m2 = t2.m2) AND
> (t1.m3 = t2.m3))
Well, there's our problem: an estimate of 1 row for a join that's
actually 30805113 rows is uncool :-(.
It's hard to tell whether the planner is just being overoptimistic
about the results of ANDing the three join conditions, or if one or
more of the basic condition selectivities were misestimated. Could
you try
explain analyze select 1 from t1, t2 where t1.m1 = t2.m1;
explain analyze select 1 from t1, t2 where t1.m2 = t2.m2;
explain analyze select 1 from t1, t2 where t1.m3 = t2.m3;
and show the results? This will probably be slow too, but we don't
care --- we just need to see the estimated and actual rowcounts.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-01-25 02:31:14 | Re: 8.3rc1 Out of memory when performing update |
Previous Message | Fernando Ike | 2008-01-25 01:53:52 | Re: Configuration settings (shared_buffers, etc) in Linux: puzzled |