[mythtv-users] Slow MySQL query after delete

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Tue Sep 4 20:34:58 UTC 2007

    > Date: Tue, 04 Sep 2007 12:01:06 -0400
    > From: "Michael T. Dean" <mtdean at thirdcontact.com>

To take a contrary view, with my tongue only partially in-cheek,
and with the hope of getting actual information and -please- not
a flamewar:

    > The high-level overview is that we're going to move to an embedded MySQL
    > (if the users don't see a DB, they can't complain about it) that can be

But they can still be shafted by its misbehavior---while being less
able to talk coherently about why things are going wrong.  And if
things like phpmyadmin become unusable, it becomes even harder to
poke around while debugging.

E.g., while it might remove certain misconfiguration bugs, it also
means users might not be able to debug certain issues as effectively
if too much is "under the hood".  Without either scheduler or schema
changes, it seems to me that this wouldn't actually fix the "slow
queries" issue unless the embedded MySQL magically has vastly superior
performance to regular MySQL, which seems unlikely.

[I must confess to never having seen a clear explanation of why
embedded MySQL is on the roadmap, but we're talking about at least
two years of traffic on the -dev list and no doubt I've forgotten the
crucial thread; presumably you can send some cogent pointers. :) Ditto
the vehement objections to making Myth interoperable with non-MySQL
implementations at all, e.g., the rather unfortunate reactions when
someone a few months ago was trying to allow migration to Postgres,
which -doesn't- seem to require the daily table-fixing cargo cult
ritual to stay operational and performant, and doesn't seem to get
the same sorts of snickers from database people that MySQL does.]

    > configured and optimized automatically and have a "mythdata" server-type
    > program that provides all access to the data so clients do not need to
    > use SQL.

...but would, I hope, still have the -option- to use it, in cases
where they are extending Myth's functionality in ways that are either
unanticipated by the devs, or appropriate only for one particular
site.  (E.g., we have automation that uses Myth as a frontend for
its own work, but nobody else needs what we're doing.)  Lacking this
sort of access, the last non-embedded Myth would be the last one we
could use.

More information about the mythtv-users mailing list