Mailing List Archive

Table types and locking
A few days back someone suggested that we could switch the tables from
MyISAM to InnoDB to help avoid slowdowns where the whole system is
waiting on a table lock to be released, without having to rewrite as
much of our code as we would to change to a different dbms such as
postgres. But, the fulltext indexing we use to drive the search engine
only works on MyISAM tables.

However... with MySQL not all tables in a database have to be of the
same type. There are already separate columns for the fulltext index
thanks to the need to strip out markup; why not move them out to a
separate table, keyed to the cur_id, and make it MyISAM while the other
tables move to InnoDB?

It'd only be written to on page edit and deletion, and only read on
search and mispeelings, so there'd be less contention on it than there
is on the much-abused cur table. And for extra bonus points, the current
revisions download dump wouldn't be weighted down by the stripped copy
of every article's text.

We may have to recompile MySQL to enable InnoDB, but relatively little
of our code should have to change to take advantage of it.

-- brion vibber (brion @ pobox.com)
RE: Table types and locking [ In reply to ]
I like the idea of moving the fulltext column to a separate table, keyed to the cur_id. That's the kind of normalization that can't hurt, and is likely to help.

Ed Poor
Re: Table types and locking [ In reply to ]
On Sam, 2002-11-23 at 00:15, Brion Vibber wrote:

> However... with MySQL not all tables in a database have to be of the
> same type. There are already separate columns for the fulltext index
> thanks to the need to strip out markup; why not move them out to a
> separate table, keyed to the cur_id, and make it MyISAM while the other
> tables move to InnoDB?

I see no reason why this shouldn't work. Let's give it a try!

Regards,

Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de