List:Falcon Storage Engine« Previous MessageNext Message »
From:Christopher Powers Date:January 30 2009 12:21am
Subject:Re: TABLE OPTIMIZE
View as plain text  
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
> 
> 

Thread
TABLE OPTIMIZEChristopher Powers29 Jan
  • RE: TABLE OPTIMIZEVladislav Vaintroub30 Jan
    • Re: TABLE OPTIMIZEChristopher Powers30 Jan
      • RE: TABLE OPTIMIZEVladislav Vaintroub30 Jan