Hi!
On Feb 21, HMax wrote:
> So this means we cannot combine both FULLTEXT and classical indexes if
> we want to use a LOAD INDEX INTO CACHE, and that we won't ever be able
> to ?
No. FULLTEXT indexes now have small block size (1024) so they should
load ok. Only long varchar indexes will be a problem (but not
'ever', see below :)
> How about being able to specify the indexes we want to load into the
> cache. It's supposed to work this way (but it is told in the doc it
> doesn't yet). This would solve the problem I believe, if we specify
> what index we want in cache.
Right, it's in the TODO.
Here's the problem: LOAD INDEX reads the complete MYI file
sequentially, block after a block, and loads them in cache.
If blocks would have different sizes it would be not possible, because
block header does not store block size.
Loading only a selected index does not work either, because block
header does not store what index it belongs to.
The only solution would be to traverse the index tree from the root -
but it'd be slow, because it implies random reads from the index file
:(
Instead, we plan to store index number in every block, but it means
incompatible change in MYI file format, so it's not for 4.1 (and not
even for 5.0 which is almost frozen now).
> What I don't undestand is that when not cached using LOAD INDEX INTO
> CACHE, FULLTEXT indexes can be into cache, the ones on VARCHAR too,
> and this does not see to cause any trouble.
See above, regular btree traversal is not a problem. Sequential MYI file
access is.
> But using LOAD INDEX, it doesn't work. Is there really no workaround ?
> We have for about 1.5Go of fulltext indexes and if they were in cache,
> this would speed up things so much !
It's fixed in 4.1.8.
Regards,
Sergei
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik <[EMAIL PROTECTED]>
/ /|_/ / // /\ \/ /_/ / /__ MySQL AB, Senior Software Developer
/_/ /_/\_, /___/\___\_\___/ Osnabrueck, Germany
<___/ www.mysql.com
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
