gt;
To: Doug Eck <[EMAIL PROTECTED]>
Cc: pgsql-performance@postgresql.org
Sent: Monday, September 29, 2008 6:20:20 PM
Subject: Re: [PERFORM] Identical DB's, different execution plans
Doug Eck <[EMAIL PROTECTED]> writes:
> The new plan from the slower db:
>-> Index Sca
Doug Eck <[EMAIL PROTECTED]> writes:
> The new plan from the slower db:
>-> Index Scan using t1_uc2 on t1 (cost=0.00..25604.74 rows=204906
> width=32) (actual time=0.061..327.285 rows=8438 loops=1)
> Filter: active
This seems a bit fishy. In the first place, with such a simple fi
e
from
t1,
t2
where
t2.eff_dt = current_date
and t1.active = true
and t1.bn = t2.sn;
Thanks.
- Original Message
From: Tom Lane <[EMAIL PROTECTED]>
To: Doug Eck <[EMAIL PROTECTED]>
Cc: pgsql-performance@postgresql.org
Sent: Monday, September 29, 2008 11:42:01 AM
Doug Eck <[EMAIL PROTECTED]> writes:
> Any ideas as to what could the first db to opt for the slower subquery rather
> than the merge?
Not from the information given. Presumably db1 thinks that the
mergejoin plan would be slower, but why it thinks that isn't clear yet.
Try setting enable_nestloo
I have two identical databases that run the same query each morning. Starting
this morning, something caused the first db to start using a different
execution plan for the query, resulting in much worse performance. I've have
tried several things this morning, but I am currently stumped on wha
