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:t...@sss.pgh.pa.us] Sent: Tuesday, May 20, 2014 12:22 AM To: Huang, Suya Cc: pgsql-performance@postgresql.org Subject: Re: [PERFORM] same query different execution plan (hash join vs. semi-hash join) "Huang, Suya" <suya.hu...@au.experian.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 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
