Hi, On 01/17/2012 11:54 AM, Paul Poulain wrote:
* innoDB has a *big* problem with deletion, and space is not retrived. so those tables, that have temporary data only are good candidates to be myISAM
Although as long as one uses the innodb_file_per_table option, recovering space from InnoDB scratch tables is easy.
* those tables don't have any foreign constraint, that myISAM don't manage, so it's OK
message_queue does have constraints, actually, and justifiably so if one uses it as a log of notifications sent to the patron.
* those tables are very small, fast to write, so the lock table issue that Colin rises is not a big deal.
Well, depends on scale. I could imagine very large Koha sites that retain message history having large message_queue tables.
We have this on all our customers, without any performance issue. (not sure for merge_authorities, but sure for sessions& zebraqueue)
Faster yet, of course, is to not store sessions in MySQL at all, and use memcached. Of course, the tradeoff is a little more work if one wishes to run reports on OPAC sessions. All of that said, MyISAM is a reasonable choice for a default storage enginge for sessions, zebraqueue, and need_merge_authorities. Regards, Galen -- Galen Charlton Director of Support and Implementation Equinox Software, Inc. / The Open Source Experts email: gmc@esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org