From: | "Huang, Suya" <Suya(dot)Huang(at)au(dot)experian(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: same query different execution plan (hash join vs. semi-hash join) |
Date: | 2014-05-23 00:16:02 |
Message-ID: | D83E55F5F4D99B4A9B4C4E259E6227CD0149AD18@AUX1EXC01.apac.experian.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Thanks Tom, I think you're right. I just did an analyze on table test1 and the execution plan now generated is more stable and predictable.
Thanks,
Suya
-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Tuesday, May 20, 2014 12:22 AM
To: Huang, Suya
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: [PERFORM] same query different execution plan (hash join vs. semi-hash join)
"Huang, Suya" <Suya(dot)Huang(at)au(dot)experian(dot)com> writes:
> Thank you Tom. But the time spent on scanning table test1 is less than 1 second (91.738 compares to 87.869), so I guess this shouldn't be the issue?
No, the point is that the bad rowcount estimate (and, possibly, lack of stats about join column contents) causes the planner to pick a join method that's not ideal for this query.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitris Karampinas | 2014-05-23 14:40:31 | Re: Profiling PostgreSQL |
Previous Message | Michael Paquier | 2014-05-22 23:39:26 | Re: Profiling PostgreSQL |