Jon,
an update statement is supposed to return the # of rows updated, so the client must wait for a response, which means the client will wait if you low_priority your updates. But if they are insert delayed then the client gets a return immediately. This behavior limits the usefullness of low priority with updates. I did ask on the list if there were any plans for a delayed update, but I was told there aren't.
Trevor
Jon Drukman wrote:
Dathan Vance Pattishall wrote:
log-bin=/var/opt/mysql/db2-binlog skip-innodb log-error=/var/opt/mysql/db2-errlog
This is on a separate drive?
yes, the database is the only thing on the high speed RAID. everything else is on the other drive (also a RAID but only RAID0 with 2 drives).
any ideas appreciated!
Try setting low-priority-updates and delay-key-write=ALL
i haven't tried this yet, but one of the other developers has objected that doing this will kill performance for people posting messages because their clients will hang waiting for the selects to finish. is this true?
Your running into a concurrency issue, the only other quick fix is to use
innodb, but your blobs will kill you in disk space.
hmmmm we've got approx 60G free on the RAID so this may not be such a big problem.
-jsd-
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
