> > But I did ask for a release date of version 4.1. > > When it's ready.
That's a tautological answer. > > A nice thing with a stored procedure is that you can lower the load > > impact made by heavy queries on the database by using cursors to soften > > the performance hit they are likely to make - e.g. make the query behave > > like a high intensive interactive user instead of a huge one single > > shot batch job. > > It sounds like cursors are the feature that improves performance, not stored > procedures. Cursors are another item on MySQL's TODO list. (Planned for > 4.1 or 4.2) That was, unfortunately bad news. > > Let's say I need to do 10 millions inserts. In what way will bundling > > all these 10 million inserts into one single batch give me some gain? > > Bundling them into batches of say 1,000 will minimize the number of disk > operations MySQL must perform. Well, but now the claim was to bundle all the little small bundles to one big bundle to increase performance. So saying that I now should make the big bundle into a little bundle is not really confirming with the original statement - rather contradicting it. > > > If your database supports lock tables (like MySQL and Oracle), this > > > should help to ensure that the index cache is only flushed once after > > > all updates. > > > > If you have a frequent interactive used system, then the time spent > > in high transaction isolation levels should kept to a minimum. > > > > Giving general thump rule advices about how to implimenbt a system > > whithout having knowledge about the intention of a system is like > > saying that one should spit on the left side of the boat - just to > > bad if you have the wind in the face when you do it... > > That's funny, I read the statement to be of the form "using X can minimize > Y", (X = "LOCK TABLES", Y=index cache flush events) whereas you seem to have > read it as "use X to improve performance". Since you cut away the part I - really - gave the remark on, it is a bit hard for me to make any statement on that comment. > The author was not giving generic advice of how to make things faster, he > was giving specific advice on how to avoid a particular performance problem. That's only your opinion in the question and has nothing to do with the real facts. --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
