On Wed, 9 Mar 2005, Michael McFarland wrote:
> I continue to be stumped by this. You are right that I should have
> listed the estimates provided by explain... basically for the select where
> bar = 41, it's estimating there will be 40,000 rows instead of 7, out of
> what's actuallly 5 millio
I continue to be stumped by this. You are right that I should have
listed the estimates provided by explain... basically for the select where
bar = 41, it's estimating there will be 40,000 rows instead of 7, out of
what's actuallly 5 million records in the table.
So far I've tried inc
On Mon, 7 Mar 2005, Michael McFarland wrote:
>I'm trying to understand why a particular query is slow, and it seems
> like the optimizer is choosing a strange plan. See this summary:
>
>
> * I have a large table, with an index on the primary key 'id' and on a
> field 'foo'.
> > select count(*
Michael McFarland wrote:
I'm trying to understand why a particular query is slow, and it
seems like the optimizer is choosing a strange plan. See this summary:
...
explain select * from foo where barId = 412 order by id desc limit 25;
Limit ()
-> Index scan backward using primarykey_index
I'm trying to understand why a particular query is slow, and it seems
like the optimizer is choosing a strange plan. See this summary:
* I have a large table, with an index on the primary key 'id' and on a
field 'foo'.
select count(*) from foo;
1,000,000
select count(*) from foo where bar =
