Dmitry Koterov wrote:
> I don't know exactly is it your case, but sometimes
>
> SET enable_sort = off;
>
> speeds up some queries by the factor of hundred. But in some cases this
> command slows down operations, so I TEMPORARILY switch enable_sort on and
> off for some queries. It affects the que
I don't know exactly is it your case, but sometimes
SET enable_sort = off;
speeds up some queries by the factor of hundred. But in some cases this
command slows down operations, so I TEMPORARILY switch enable_sort on and
off for some queries. It affects the query plan greatly.
On 3/20/07, Alban
Tom Lane wrote:
> Alban Hertroys <[EMAIL PROTECTED]> writes:
>> It seems pretty obvious that the planner underestimates the cost of
>> nestloops here, is there some way to tweak this?
>
> The real problem is the factor-of-a-thousand underestimate of the size
> of this join:
Good observation, I mi
Alban Hertroys <[EMAIL PROTECTED]> writes:
> It seems pretty obvious that the planner underestimates the cost of
> nestloops here, is there some way to tweak this?
The real problem is the factor-of-a-thousand underestimate of the size
of this join:
>-> Nested Loop (cost=0.00..281.74 rows=2
Alban Hertroys wrote:
> I have a query here for which postgres chooses a nested loop, for which
> it takes ~19s to complete in the worst-case (measured). However, if I
> disable nestloops it completes in ~400ms...
>
> It seems pretty obvious that the planner underestimates the cost of
> nestloops
I have a query here for which postgres chooses a nested loop, for which
it takes ~19s to complete in the worst-case (measured). However, if I
disable nestloops it completes in ~400ms...
It seems pretty obvious that the planner underestimates the cost of
nestloops here, is there some way to tweak t
