|
|
|
September 25th, 2009
11:18 am - Query cache = useless?
Following up on Mark Callaghan's blog post on how useful query cache is nowadays.
One has to say it aloud at last: let's kill it. Say, in 5.4.
It's useless on modern hardware anyway, and if you look at re-designing it, it turns out there is need for multiple solutions, since no single one performs well in all caching workloads.
What would it give our users? One less gotcha-like feature in the server that they need to learn, learn to forget. It will open up a niche for third-party projects to contribute. And the core server development team will have one less thing to worry about.
|
June 29th, 2007
07:17 pm - Query cache is slow to the point of being unusable - what is being done about that.
We spent a lot of time this month trying to fix Bug#21074 "Large query_cache freezes mysql server sporadically under heavy load".
In a nutshell, invalidation of a table can be dead slow (seconds) when there are tens of thousands of cached queries associated with this table, and, moreover, invalidation
freezes the entire server when it happens.
It's so funny, this thing happens under two singleton mutexes (one instance of the mutex exists in the entire server) both of which are required for every single query that the server gets.
Invalidation is indeed somewhat slow, but making it a bit faster will only shift the threshold when the query cache becomes unusable from tens of thousands of cached results, to, say, hundreds of thousands. So we thought it'll only change the depth of the hole in which people will discover they've shoot themselves in the foot.
Besides, any change of that sort requires quite an overhaul of internal data structures in the cache - not something one would do at a beta stage (the work is being done for 5.1).
So, instead, we're trying to make the whole thing more concurrent. Eek, perhaps these two singleton mutexes are not needed after all?
LOCK_open was taken in mysql_rm_table_part2. This thing does the actual job of DROP TABLE.
That place we fixed to take an exclusive name lock on the table instead of keeping the entire
system frozen (good for other things as well). Thanks to some prior patch that was done by Dmitri earlier this year in 5.1, exclusive name locks on table metadata are now possible.
The problem with structure_guard_mutex was harder to crack. The thing is, invalidation of one table may potentially trigger invalidation of every single result in the query cache,
and that's not known in advance, and there is no way to lock a sub-part of the cache and then
shift the lock to some other part.
And implementing this would, again, mean, changing the whole thing quite a bit.
So we now simply disable the cache during invalidation.
Now, I'm writing this to get beaten. If it's wrong and will break your application, please tell. If, on the contrary, you like the idea and want to test it, stay tuned. The patch is not yet in, but soon will be.
|
05:54 pm - My top 5 MySQL wishes
There has been a trend in the blogs for top5 MySQL wishes.
Many people, including Ronald Bradford, Alan Kasindorf, Jim Winstead, Jonathon Coombes, Jeremy Cole, Jay Pipes, Antony Curtis, Stewart Smith coined in.
Here're my 5:
1. Remove excessive fuss. OK, we know what needs to be done, just give us time to get things in order. Anything related to MySQL gets huge visibility, and we tend to overestimate the importance of "opinion of community". If you have a cool new feature for the server or a cool new wish, let it cook for a while. If you have or want to write a patch, first get in touch with developers, discuss things on internals@ or commits@, then post your patch on the Forge and see if it takes off. Be sure it'll get in if it's a really good idea. But not next week. Perhaps in a year or two. Want your code to be accepted faster? Write a good fix for a bug. We have 1100 of them. Still want it in faster? Fix a crash.
2. Open the development process. This is the other side of the previous wish. It takes a year or two to introduce a new engineer into all the existing conventions. So an external engineer just can't write a good patch for the server. Besides, we mostly in need of contributions that improve and simplify the existing code base, not add new code. But it is increasingly hard to change the existing code -- implicit dependencies, no good tests, almost non-existent unit test coverage. This is a barrier for penetration, and it's a catch, catch-22.
3. Get to a normal release schedule. Have XXX.1, XXX.2, XXX.3 releases once or twice a year. There is a lot in this wish that makes it very hard to satisfy -- planning, compatibility, healthy life cycle, high quality support. But we do need to shift the load of patches pushed to the period when a version is in alpha, not when it's in GA, and we do need to release more often.
4. Establish productive relationship with the majority of users. Something tells me that visibility does not equate to quality of input, and we get most of our input from early adopters, not from the large majority. We need this for the next wish:
5. Find a way to do incompatible changes with minimal pain for users. If we don't deprecate the 'cool non-standard features most needed now' that were added during brave times of 3.23 and 4.0, the software is a dead fish.
|
November 15th, 2006
07:56 pm - DROP TRIGGER IF NOT EXISTS
Despite a hard stop for new features in 5.0, we are adding IF EXISTS syntax to DROP TRIGGER statement.
I wonder what needs to happen to have basic SIGNAL functionality added. I tried to implement it a few months ago and it didn't seem bigger than a task for a few days.
So, I'm looking for ideas how to make addition of SIGNAL to 5.0 a no-brainer decision. Should our community run a charity auction with this feature on stake?
Finding a customer from Fortune 500 that would declare they can't use our product without it might prove more effective :)
|
November 9th, 2006
02:00 am - MySQL syntax highlighting in Vim
I didn't know such a thing exists.
kostja@bodhi:/usr/share/vim/vim70/syntax> ls -al mysql.vim
-rw-r--r-- 1 root root 16078 2006-05-24 20:16 mysql.vim
( Read more... )
Current Music: Thievery Corporation, The Heart`s A Lonely Hunter
|
March 24th, 2006
04:14 pm - Counting prepared statements
Finally found time to fix Bug#16365, which is a request to add a limit for the total number of prepared statements in the server. It turns out to be a pretty useful feature, at least I was able to find 4 statement leaks in the test suite with it. The patch adds server variables to limit and monitor the count of prepared statements:
mysql> show variables like '%stmt%';
------------------------- -------
| Variable_name | Value |
------------------------- -------
| max_prepared_stmt_count | 16382 |
| prepared_stmt_count | 0 |
------------------------- -------
2 rows in set (0.00 sec)
Notice that this is slightly different from the status information, as in the status we account for all prepares and executes, including unsuccessful ones:
( Read more... )
|
January 26th, 2006
04:59 pm - Reading: Computers
A few recent books:
"Foundation for Future Database Systems. The Third Manifesto" by C.J. Date and Hugh Darwen.
An interesting and controversial book. In many cases completely rejects some practical arguments for the sake of purity of the model. A funny book too, as according to it, SQL is not a true relational language, which is a good reference to use when fingers are pointed at MySQL not being a relational database. Also gave a valuable insight why Bug#5719 should not be fixed. Despite this high appraisal, I don't think the book matches its title.
"C++ Coding Standards" by Herb Sutter and Andrei Alexandrescu.
A must-have book for C++ programmers, 200 pages of best programming style practices: basically, a summary of well-known sources, but now from the horse's mouth.
"Exceptional C++ Style" by Herb Sutter. Looks like the contents of the book is available online, just like it was with "Exceptional C++". I liked the previous book, so I bought (but haven't read yet) this one too.
|
January 2nd, 2006
05:12 pm - The case of a color-blind painter.
I'm happy it turned out to be that simple, but the amount of such bugs and devastating consequences are humiliating.
Bug#7209 is a case of an intermittent failure when the best brain of Support department and dozens of man hours had to be spent to track the issue down to a repeatable test case. And the cause is such a trivial design mistake:
( Read more... )
|
December 24th, 2005
12:48 pm - MySQL Users Conference 2006
I've just got an email that I was accepted as a presenter for the MySQL Users Conference 2006. My 45 minute session is devoted to "Dynamic SQL in Stored Procedures", which I honestly know little about, except that I implemented the feature.
( Read more... )
|
December 23rd, 2005
05:35 pm - The next DevCon is in Sorrento
Yay! Can't wait for March 2006 to come :). There is a little problem though, the evergrowing list of bugs :( We made the numbers for our team go under 100 last month only to see it grow back to 120 while me and Dmitri were on vacation :(
|
October 21st, 2005
10:16 pm - How to browse MySQL source repository.
Online access to the source repository: http://mysql.bkbits.net:8080/mysql-5.0
A web interface for the mailing list which receives all commit mails: http://lists.mysql.com/commits
|
May 19th, 2005
01:06 pm - Us and RedHat
As a growing company, we're following the track of Red Hat. Are we ready to eventually have two versions like they do, Advanced Server and Fedora? This is where it is going to end, and it is not fun.
|
11:55 am - MySQL Users Conference 2005
MySQL UC 2005 was a success: more attendees, more advanced. We apparently pulled through with 4.1, which is good, and were given another chance with 5.0, and this is not so good: if this trend continues, we may develop a mentality of naval college. But there are dangers all over the place anyway.
|
December 18th, 2004
12:55 pm - everyone wants full monty
kostja@dragonfly:~> vim .irclogs/mysql/mo^T
monty.log monty\|codeing.log monty\|night.log
monty_away.log monty\|debug.log monty\|phone.log
monty_evening.log monty\|dinner.log monty\|sauna.log
monty\|away.log monty\|email.log monty\|shop.log
monty\|back0130.log monty\|evening.log monty\|squash.log
monty\|back1600.log monty\|food.log monty\|travel.log
monty\|back1700.log monty\|housework.log monty\|travel_away.log
monty\|back2200.log monty\|later.log monty\|weekend.log
monty\|back_late.log monty\|lunch.log monty\|zzz.log
monty\|brb.log monty\|meeting.log monty\|zzzz.log
monty\|breakfast.log monty\|movie.log
|
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
kostja_osipov's journal