>>>>> "Antony" == Antony T Curtis <antony@stripped> writes:
Antony> Michael Widenius wrote:
>> Sorry for the delayed reply; I have been on a vacation for a week and
>> are slowly catching up with all old emails.
Antony> No probs... Glad you're back and hope you enjoyed your holiday.
Yes, I had a wonderful time. The only regret I have is that I didn't
visit Rio sooner...
>> The problem is that the above will only work if a major part of the
>> keys are identical in the first n-1 parts. (You would guess that at
>> least 1/3 of the keys must be identical per key block for this to
>> work, which is not a very common situation).
>> The major problem is that when it comes to scan indexes compared to
>> scan a fixed length data file, index scanning is at least 3 times
>> slower than data file scanning (for B-trees). The reason is that
>> there is much more seeks involved when scanning the index structure
>> and also because the index structure is more complicated than the data
>> file structure, especially when we talk about compressed indexes.
Antony> This method for searches is currently used by the legacy database used
Antony> here where the developers hand-write it for where they want to use it -
Antony> they call it bounce/bump index searches.
Do your legacy database save the index separately or together with the
Antony> Perhaps it could be made available on a per-table or per-handler (as a
Antony> flag), or even some variable the user may set.
If we do something like this, we would have an option in the handler
if this optimization is a good thing for this table handler; We
already do a lot of things like that.
Antony> I think I'd read up on the code and see if I could develop an
Antony> implementation... If I get anything to work, this list would be the
Antony> first to know... Perhaps a useful feature to add in to 4.0.x
Antony> As an aside, is there a timescale for 4.0.x? I'd really like to see
Antony> unions and views ;)
4.0 will only have a new .frm format; This will however be the base
stone for adding views to 4.1. (Unions are so simple that it may be that
they will be available in 4.0.x)
We have just 1-2 weeks more work to get out MySQL 3.23.x with BDB and
Innobase tables. As soon as this is done we will continue with the
4.0 tree and try to get out a alpha within a few weeks, one which we
will then do all the things that are on the 4.0 TODO in the MySQL manual.