[Koha-devel] Tables from InnoDB to MYISAM

[Galen Charlton]

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 at 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