Harrison Fisk wrote:
>
> There isn't really any way to "use" concurrent INSERT. It happens
> automatically if possible. However there are a few things you can do
> to help it along, such as OPTIMIZE after you DELETE large portions of
> the table. Also it does have to enabled in LOAD DATA INFILE
> manually. However, regular INSERTs and SELECTs should do this
> automatically.
Well... in order to "use" concurrent insert you need to prevent tables
with deleted data. So the developer just needs to make sure they're
always in this situation.
> Why do you think this is your bottleneck? Have you measured anything
> quantitatively? What is your table_locks_immediate vs. your
> table_locks_waited? What is your rate of INSERTs?
This is a good idea actually. I took a look at these values and only
3.6% of our queries wait for locks.
Of course the problem might be that these locks take up a lot of time in
critical places. It would be nice to see these values broken down into
seconds waited..... but this is probably too much to ask for just yet ;)
Kevin
--
Use Rojo (RSS/Atom aggregator)! - visit http://rojo.com.
See irc.freenode.net #rojo if you want to chat.
Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html
Kevin A. Burton, Location - San Francisco, CA
AIM/YIM - sfburtonator, Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
