[mythtv-users] Slow MySQL query after delete

[Chris Pinkham]

* On Wed Dec 05, 2007 at 12:16:45AM -0500, Michael T. Dean wrote:
> 2007-12-04 22:00:08.327 scheduler: Scheduled items: Scheduled 265 items
> in 2.8 = 0.00 match + 2.79 place

It probably doesn't affect you much, but tonight I found an issue
in the interaction between the delete code on the frontend and the
scheduler on the backend.  In current SVN, with the new Watch List,
we update the 'last_delete' field in the record table whenever we
delete a recording.  This is done on the frontend before it tells
the backend to delete the recording.  This update hangs if the
scheduler is currently running because the scheduler has an implicit
read-only lock on the record table.  So, for people who have long
scheduler runs, if they try to delete a recording while the
scheduler is running, they will experience a hang on the frontend
until the scheduler's BUQ is finished.

I'm sure you saw it, but for other's reading this thread, I did
commit a patch tonight which will eliminate the reload of the complete
recording list every time you delete a recording.  This was happening
twice for every recording deleted (unless you did them fairly close
together and have slow deletes turned off).  With the current code,
the frontend will delete the recording's info from its in-memory
program cache rather than reloading the complete list from the
backend.  This applies whenever a recording is deleted, whether it
is manual by the user or by the autoexpirer or by another user on
another frontend.

http://svn.mythtv.org/trac/changeset/15059

--
Chris