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: [email protected]
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
_______________________________________________
Koha-devel mailing list
[email protected]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/
