Ben Chobot writes:
> Awesome, that did the trick. Thanks Tom! So I understand better, why is my
> case not the normal, better case?
Well, the short answer is that the 8.4 changes here are in the nature of
two steps forward and one step back. The long-term goal is to increase
the planner's abili
Awesome, that did the trick. Thanks Tom! So I understand better, why is my case
not the normal, better case?
(I assume the long-term fix is post-9.0, right?)
On Feb 15, 2010, at 9:26 AM, Tom Lane wrote:
> Ben Chobot writes:
>> On Feb 15, 2010, at 7:59 AM, Kevin Grittner wrote:
>>> Could you sh
Ben Chobot writes:
> On Feb 15, 2010, at 7:59 AM, Kevin Grittner wrote:
>> Could you show the query, along with table definitions (including
>> indexes)?
> Oh, yeah, I suppose that would help. :)
> http://wood.silentmedia.com/bench/query_and_definitions
It looks like the problem is that the EXI
On Feb 15, 2010, at 7:59 AM, Kevin Grittner wrote:
> Could you show the query, along with table definitions (including
> indexes)?
Oh, yeah, I suppose that would help. :)
http://wood.silentmedia.com/bench/query_and_definitions
(I'd paste them here for posterity but I speculate the reason my fir
Ben Chobot wrote:
> Here is the plan on 8.4.2:
> Here is the very much less compact plan for the same query on
> 8.1.19:
Could you show the query, along with table definitions (including
indexes)?
-Kevin
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To mak
Can you force 8.4 to generate the same plan as 8.1? For example by running
SET enable_hashjoin = off;
before you run EXPLAIN on the query? If so, then we can compare the
numbers from the forced plan with the old plan and maybe figure out why it
didn't use the same old plan in 8.4 as it did in 8
