Re: Any better plan for this query?.. - Mailing list pgsql-performance

From Simon Riggs
Subject Re: Any better plan for this query?..
Date
Msg-id 1241645035.6109.26.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Any better plan for this query?..  (Dimitri <dimitrik.fr@gmail.com>)
Responses Re: Any better plan for this query?..  (Dimitri <dimitrik.fr@gmail.com>)
Re: Any better plan for this query?..  (Gregory Stark <stark@enterprisedb.com>)
List 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


pgsql-performance by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Transparent table partitioning in future version of PG?
Next
From: Tom Lane
Date:
Subject: Re: Transparent table partitioning in future version of PG?