Thanks You,
I changed the random_page_cost to 2 and the query plan has changed and
speeds up.
I will check the other queries but I think I will leave it at this
value.
Thank you again.
Kaloyan Iliev
Robert Haas wrote:
On Fri, Jan 8, 2010 at 2:23 PM, Tom Lane wrote:
I
On Fri, Jan 8, 2010 at 2:23 PM, Tom Lane wrote:
>> If the other plan does turn out to be faster (and I agree with Tom
>> that there is no guarantee of that), then one thing to check is
>> whether seq_page_cost and random_page_cost are set too high. If the
>> data is all cached, the default values
Robert Haas writes:
> On Fri, Jan 8, 2010 at 1:27 PM, Tom Lane wrote:
>> 11000 index probes aren't exactly free. If they take more than about
>> 1msec apiece, the planner picked the right plan.
> The OP could try setting enable_hashjoin to false (just for testing,
> never for production) and do
On Fri, Jan 8, 2010 at 1:27 PM, Tom Lane wrote:
> Kaloyan Iliev Iliev writes:
>> My question is why the planner didn't do the index scan first on ms_data
>> to reduce the rows to ~ 11000 and the use the PK index on
>> ms_commands_history.
>
> 11000 index probes aren't exactly free. If they take
Kaloyan Iliev Iliev writes:
> My question is why the planner didn't do the index scan first on ms_data
> to reduce the rows to ~ 11000 and the use the PK index on
> ms_commands_history.
11000 index probes aren't exactly free. If they take more than about
1msec apiece, the planner picked the ri
Hi ,
I have a simple query with two tables.
ms_data ~ 450 rows
ms_commands_history ~ 50 rows
I have done analyze and there are indexes.
My question is why the planner didn't do the index scan first on ms_data
to reduce the rows to ~ 11000 and the use the PK index on
ms_commands_history
