Actually the more I read on hash indexes and think about the way this
table is behaving, it does seem to be a hash index - despite being
reported as a btree. I've gotten up to 4mil rows (4 db nodes, 2
fragments, 1G ram each), and looking up a single row based on the
indexed value is almost instantaneous, but asking for anything ordered,
or a range of values, takes for ever.
Thanks,
Devananda
Devananda wrote:
> That would make sense (and thanks for bringing that to my attention).
> However, show indexes reports that it is a BTREE, not a HASH. :-/
>
> mysql> show indexes from tdata;
> | tdata | 1 | i2 | 1 | username |
> NULL | NULL | NULL | NULL | | BTREE
> | |
>
>
> Devananda
>
>
> Jeremy Zawodny wrote:
>
>> Doesn't NDB primarily used hash indexes? If so, how would you expect
>> them to help? It's like HEAP tables before MySQL 4.1.
>>
>> Jeremy
>>
>>
>
>
