Vladislav Vaintroub wrote:
> Any reason to support table optimize;)?
I LOVE answers like that. You tell me...I'm open to ideas.
Here's the issue:
Table::optimize() first fetches all the records in the table to get the
record cardinality. If we release each record after the fetch, no
problem. The following call to Index::optimize, however, executes a
SELECT for each index, like this:
SELECT count(*) FROM (SELECT DISTINCT S1 FROM TEST.T)
The SELECT, of course, fetches each record in the index. If the table is
large enough, this will overflow the record cache very quickly.
I suppose Index::optimize() could be optimized to operate in a more
modular fashion, or we could just say that the record cache has to be
sized appropriately. Backlogging doesn't come into play because there
are no record inserts and thus no chills.
>> -----Original Message-----
>> From: Christopher.Powers@stripped [mailto:Christopher.Powers@stripped]
>> Sent: Thursday, January 29, 2009 11:55 PM
>> To: Kevin Lewis
>> Cc: FalconDev
>> Subject: TABLE OPTIMIZE
>>
>> Hi again. New issue.
>>
>> TABLE OPTIMIZE refreshes the record and index cardinality for a table.
>> Record cardinality is determined by fetching every record in the table.
>> Each fetch loads a record into the record cache, where it remains
>> unscavengeable (useCount > 1) until the transaction completes.
>>
>> Any reason not to release each record after it has been fetched and
>> counted?
>>
>> Chris
>>
>> --
>> Falcon Storage Engine Mailing List
>> For list archives: http://lists.mysql.com/falcon
>> To unsubscribe: http://lists.mysql.com/falcon?unsub=1
>
>
