| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Dimitri <dimitrik(dot)fr(at)gmail(dot)com> |
| Cc: | PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Any better plan for this query?.. |
| Date: | 2009-05-06 21:23:55 |
| Message-ID: | 1241645035.6109.26.camel@ebony.2ndQuadrant |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Wed, 2009-05-06 at 10:31 +0200, Dimitri wrote:
> I've already tried a target 1000 and the only thing it changes
> comparing to the current 100 (default) is instead of 2404 rows it says
> 240 rows, but the plan remaining the same..
Try both of these things
* REINDEX on the index being used in the query, then re-EXPLAIN
* enable_hashjoin = off, then re-EXPLAIN
You should first attempt to get the same plan, then confirm it really is
faster before we worry why the optimizer hadn't picked that plan.
We already know that MySQL favors nested loop joins, so turning up a
plan that on this occasion is actually better that way is in no way
representative of general performance. Does MySQL support hash joins?
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2009-05-06 21:34:15 | Re: Transparent table partitioning in future version of PG? |
| Previous Message | Kenneth Marshall | 2009-05-06 15:49:18 | Re: Any better plan for this query?.. |