>>>>> "Tim" == Tim Bunce <Tim.Bunce@stripped> writes:
Tim> On Fri, Jan 07, 2000 at 05:15:04PM +0200, sinisa wrote:
>> Peter Zaitsev writes:
>> >
>> > I'm thinking about enabling DELAYED_KEY_WRITE for some of my table
>> > but afraid what some of my tables still open for a weeks with just a
>> > few acceses so to decrease the recovery time in case of mysql crash
>> > i want to flush my tables sometimes - but I'm wondering how exactly
>> > flush-tables works and how much it will affect perfomance ?
>> >
>> > Additionaly don't you plan any timeout to delay_key_write as time
>> > of seconds the table should be flushed ?
>>
>> DELAYED_KEY_WRITE's and flush-tables are not very much related, as far
>> as I know.
>>
>> flush-tables, close unused tables, waits and then closes used
>> tables. This forces re-opening physical files, and should be done when
>> backup should be done, or when too many file descriptors are used.
>>
>> flush-tables will empty table cache, so that all tables will have to
>> be reopened.
>>
>> It will affect performace, as opening files is *relatively* slow
>> operation.
Tim> There ought to be a form of FLUSH TABLES that doesn't _remove_ cached
Tim> information, just writes it out.
Tim> That would ensure the disk is uptodate (assuming the filehandle is set
Tim> to sync) but without paying the possibly large cost of emptying and
Tim> reloading the caches.
Tim> As Monty has added a "FLUSH TABLE foo" to his to-do list, perhaps he
Tim> could add this to it as well. Seems like a simple change and would
Tim> make flushing more efficient for most uses.
I agree; I shall look at adding this; Shouldn't be that hard...
The main reason FLUSH TABLES existed from the beginning was to force
MySQL to read the new table information when someone from the outside
of MySQL has updated the tables. In this case MySQL had to
close+reopen the tables.
Regards,
Monty
