Team,
If you are looking into memory engine redesign and have decided that B-
tree index implementation is buggy and should be removed, please also
be aware that the hash index has a community of opposition regarding
the implementation of the hash. Perhaps it is an issue only for non-
unique so perhaps in most implementations it is a non-issue. Just a
thought that a code review of the current hash index might be useful.
Please see..
http://bugs.mysql.com/bug.php?id=7817
The comments at the bottom of this page discuss it as well..
http://dev.mysql.com/doc/refman/5.0/en/memory-storage-engine.html
--
Tom Hanlon
On 20 Aug 2010, at 01:01, Prafulla wrote:
Hi
On Fri, Aug 20, 2010 at 10:14 AM, Brian Aker <[email protected]>
wrote:
Hi!
On Aug 19, 2010, at 7:17 PM, Prafulla wrote:
I would like to understand if any work is done on this project so
far. From mailing list it seems Stewart has done some work.
I believe both Stewart and I have poked at it. There are two needs:
1) An engine that can go behind the current "heap" engine that is
documented/extendable/etc. There is a long laundry list for this.
2) A concurrent, transactional engine.
How much of work is done in this regard ? Any pointer to the bzr
branch ?
I would like to take a look.
Also I would like to contribute to its development further.
Is there any design document/list of requirement for the engine that
someone has prepared?
If yes, could you please give pointer to that as well ?
Also I just saw BTree index support has been removed from memory
engine.
Is it because we are going to redesign the engine itself or there
is no much demand for Btree? It looks like there is need for Btree
index
on memory engine in real-life scenarios. At lease people seem to
be using
it.
A couple of days ago when I was going over the btree I observed
that if I ran all of the tests through it that a number of crashes/
bugs/etc showed up (and I did the same with MySQL and found
additional issues). The problem is that the b-tree support is just
not heavily tested. It should be a drop in replacement for the hash
indexes, but it is not. The hash code is pretty reliable though. I
don't really like having code in the tree that we know has issues.
I would agree that the range indexes are useful, but in their
current state I don't believe that they are that usable.
Does this help any?
Yes, I understand your point of not having code in the main tree that
has problems.
But I do think, that range indexes should be added later back to
memory engine
once we revamp it and fully test it.
--
Best Regards,
Prafulla V Tekawade
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
Tom Hanlon
[email protected]
Cloudera Certified Hadoop Developer
Certified MySQL DBA
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
