[mythtv-users] Slow MySQL query after delete

[f-myth-users at media.mit.edu]

    > Date: Tue, 04 Dec 2007 10:49:45 -0500
    > From: "Michael T. Dean" <mtdean at thirdcontact.com>

    > On 12/03/2007 10:17 PM, Yeechang Lee wrote:
    > > f-myth-users says:
    > >   
    > >> You haven't tried the critical experiment (so far as you've told us),
    > >> which is to do MORE THAN ONE in quick succession.
    > > One delete for me (whether of a single item or a playlist) from
    > > mythfrontend results in a UI pause of no more than a second. Two
    > > deletes in quick succession results in a pause of . . . no more than a
    > > second or two.

    > I got a chance to do 2 in a row (deleted one by one).  Deleting one at a 
    > time results in a delay of about 1/2 a second.  Deleting two in a row 
    > results in 2 delays of about 1/2 a second (i.e. just long enough to 
    > clear the UI and reset the "cursor").  This is with slow deleted 
    > enabled.  I did delete them back to back--they were the same show, so I 
    > didn't have to scroll to find the second to delete.

Can you post your match/place times for typical reschedules?  (If you
did, I've overlooked them somehow.)  If those times are also subsecond,
then none of the other tests will yield any interesting results, of
course, since if it's really scheduling delays that are hanging deletes,
you won't show the effect if your delays are tiny (and then the question
becomes, "Why is your scheduler running in less than a second when many
others are reporting tens of seconds?")

Err---I've -have- been assuming all along that slow deletes really do
tell the scheduler to immediately recompute (as soon as you delete the
program).  If -that- is delayed as well until all the video is deleted
and all the table entries vanish, then of course that delay will be
hidden sometime in the future.  But I was assuming the reschedule
happens immediately, since otherwise you run the risk of missing a
show if, e.g., you delete a "keep n" show and there's another of it
coming up very soon.

    > I've been saving up some shows for deleting 5 in a row (with and without 
    > slow deleted).  I seriously expect deleting 5 in a row with slow deletes 
    > enabled will result in 5 delays of about 1/2 second.  (I used to do this 
    > all the time after a business trip--I'd delete all the shows that I 
    > watched while sitting around in the airport/on planes/at the hotel--but 
    > I've been going through my old DVD library lately, so I haven't done 
    > this for a quite a few months.)

Certainly I'd think that if it hasn't gotten wedged by 3, it probably
won't get wedged by 5.

    > I also expect deleting the shows with slow deletes disabled will result 
    > in a pause of approximately 9 to 19 seconds based on the filesize (from 
    > 4 to 8.5 GiB per file) and the fact that it takes my ext3-based 
    > filesystem approximately that long to delete a file of the given sizes.  
    > If that's the case, I'm sure the scheduler query (accessing a completely 
    > different disk drive) time will be lost in the noise.

Of course---since -you- run ext3, the way to make this test tell us
anything is to first rename the actual video files out of the way and
substitute zero-length files in their places.  After all, we -know-
that ext3 is a dog when it comes to deleting large files...