| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bricklen Anderson <BAnderson(at)PresiNET(dot)com> |
| Cc: | David Gagnon <dgagnon(at)siunik(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Please help with this explain analyse... |
| Date: | 2005-11-29 00:00:30 |
| Message-ID: | 17298.1133222430@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Bricklen Anderson <BAnderson(at)PresiNET(dot)com> writes:
> Your loops are what is causing the time spent.
> eg. "actual time=0.127..17.379 rows=1154 loops=8335)" ==
> 8335*(17.379-0.127)/1000=>143 secs (if my math is correct).
As for where the problem is, I think it's the horrid misestimate of the
number of matching rows in cs_pk:
>> " -> Index Scan using cs_pk on cs (cost=0.00..12.83
>> rows=2 width=144) (actual time=0.087..444.999 rows=13587 loops=1)"
>> " Index Cond: (('M'::text = (cs.csypnum)::text)
>> AND ((cs.csglnum)::text = ("outer".glnum)::text))"
Has that table been ANALYZEd recently? How about the gl table?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Gagnon | 2005-11-29 02:16:52 | Re: Please help with this explain analyse... |
| Previous Message | Bricklen Anderson | 2005-11-28 23:46:14 | Re: Please help with this explain analyse... |