I am, you will understand, hesitant to just say go ahead and do it. I think actually it will do just fine but I really would rather not be responsible for the decision!
You will need to create the FULLTEXT index after the table is changed as well of course. We can give you the details for those.
I am concerned that innoDB tables were created when the SQL script explicitly demands MyISAM. That just shoup=ld not happen and hopefully that is the reason for the bug ticket at the host.
totally understand on the first post
so say if I was going to attempt this, theoretically of course, I should change those two tables to MyISAM first and then try to create the index I am missing?
Theoretically of course.
That would be theoretically correct.
And the theoretical FULLTEXT index on sfposts would need to be on the post-context column and the theoretical FULLTEXT index on the sftopics table would need to be on the topic_name column and they can be named anything at all as long as it is unique…
Yellow Swordfish said
That would be theoretically correct.And the theoretical FULLTEXT index on sfposts would need to be on the post-context column and the theoretical FULLTEXT index on the sftopics table would need to be on the topic_name column and they can be named anything at all as long as it is unique…
theoretically I will report back
will do, got side tracked, my chickens decided spring was here and figured they would take a walk around the neighborhood, those chickens are lucky my wife loves them, will try in the next couple minutes
Just a update, I decided to hold off until I heard back from wp-engine, their response
We do automatically force some tables to InnoDB for performance reasons. You can change the database engine on your end to create the index, but please bear in mind that it will likely be a temporary change. I wouldn’t consider this to be a bad thing, as the only consideration is from a performance side, not server stability or security.
My response back was why would it be a temporary change? Haven’t heard back yet, so since they gave me the green light, I’ve tested switching it on my staging server and it works, it works with and without creating the index. Is the index necessary?
One other weird thing I noticed, every table for simplepress is already MyISAM, the only two that are InnoDB are the sfposts and sfoptions tables, is the sfoptions being InnoDB a concern?
I did create the table and tested it, search still works fine, just want to double check this is the way to do it if needed to create it before I do it on my live site, thank-you
I dont believe it would be a concern… strange that just the two however…
that looks like the proper way to add the fulltext index…
did the search actually work without the index? by that I mean find results? can let Andy weigh in as our db expert, but perhaps its performance and other searches (ie matching) that it directly affects…
yep, worked fine without the index, well fine until a member complains any ways lol
i did open up a task for me to take a fresh look at the innoDB options as it is true that they are better performers. That will be after the release of our 5.4.2 however.
Our sfoptions table being innoDB will not matter but it hardly needs to be. It s a very small table.
Yellow Swordfish said
i did open up a task for me to take a fresh look at the innoDB options as it is true that they are better performers. That will be after the release of our 5.4.2 however.Our sfoptions table being innoDB will not matter but it hardly needs to be. It s a very small table.
Thanks Yellow, will I be fine if I do not create the index? Or is that mandatory? It seems to work with and without the index in place
Personally I would create the index if only because searches should be a little faster and more efficient with it’s existence.
done, thank-you both for your help with this, still waiting to hear back from wp-engine why they say it’s a temp fix, at least I know how to fix it if needed
I will look forward to that. Theoretically of course!
