jeremycole

15 ms·

31.
by jeremycole 13y ago
Yes, IMHO it comes from this: What would be on the news if he was a terrorist and they find out that he actually set off the explosives detector before doing his deed? So basically their response is more about fear of embarrassment (to an
32.
by jeremycole 13y ago
That article actually says "PDMI aims to replace the ubiquitous iPod cradle connector".
33.
by jeremycole 13y ago
They made so much more work for themselves in redacting by scanning at a slight angle...
34.
by jeremycole 13y ago
That's pretty silly, as any serious installation is generally using innodb_file_per_table, and thus not really subject to this problem. Nonetheless, it's a lot more complicated than it would seem to "just reclaim the space&qu
35.
by jeremycole 13y ago
You should really consider that at no time would Monty himself have received a wire transfer for a billion dollars. This "Monty got a billion dollars, what more does he want?!" thing is repeated all the time, but it's just no
36.
How does InnoDB behave without a Primary Key?(blog.jcole.us)
1 points by jeremycole 13y ago|0 comments
37.
by jeremycole 14y ago
Yeah, seems like Google is parsing the query as ((the c programming) language). It manages to map "the c programming" to the book fuzzily, and then is telling you the language of that book, which it denotes by "Original language". Awkward.
38.
InnoDB bugs found during research on InnoDB data storage(blog.jcole.us)
2 points by jeremycole 14y ago|0 comments
39.
by jeremycole 14y ago
Secrecy is keeping it this way. Every startup wants to believe that their thing, or their idea, is the most amazing thing on planet earth, and they hide it away and don't let others touch it.
40.
by jeremycole 14y ago
Yahoo and Google are both owed pretty large amounts, e.g.: http://scoweb.sco.ca.gov/UCP/PropertyDetails.aspx?propertyRe... http://scoweb.sco.ca.gov/UCP/PropertyDetails.aspx?propertyRe...
41.
Efficiently traversing InnoDB B+Trees with the page directory(blog.jcole.us)
1 points by jeremycole 14y ago|0 comments
42.
The physical structure of records in MySQL/InnoDB(blog.jcole.us)
2 points by jeremycole 14y ago|0 comments
43.
The physical structure of InnoDB index pages(blog.jcole.us)
2 points by jeremycole 14y ago|0 comments
44.
Exploring InnoDB page management with innodb_ruby(blog.jcole.us)
2 points by jeremycole 14y ago|0 comments
45.
Page management in InnoDB space files(blog.jcole.us)
2 points by jeremycole 14y ago|0 comments
46.
The basics of InnoDB space file layout(blog.jcole.us)
1 points by jeremycole 14y ago|0 comments
47.
by jeremycole 14y ago
They are related, just in somewhat strange ways. See: http://en.wikipedia.org/wiki/Mile#Roman_mile
48.
by jeremycole 14y ago
The article author is confused. I clearly stated in the presentation that we're developing our own branch of MySQL, which is available on Github: https://github.com/twitter/mysql
49.
by jeremycole 14y ago
Howdy. I was the presenter from Twitter. Aside from your bad math above, the reporter heard million when I said billion. More than 3 billion rows per day. That math is easy enough to come by if you do any math on the rest of the numbers: 40
50.
by jeremycole 15y ago
As far as I know, neither Percona nor any of the others have picked up our changes or anything like them. However we'll be working with them to get something that makes sense in a generally available release.
51.
by jeremycole 15y ago
This is actually not really about whether it makes sense, but about timelines. We expect some of this to eventually make it to upstream MySQL, but likely in a version newer than we need it in (5.6 instead of 5.5) and not for something like
52.
by jeremycole 15y ago
No, Vitess is more along the lines of our Gizzard system which has been out there for a while: https://github.com/twitter/gizzard
53.
by jeremycole 15y ago
Yup! And our changes are quite complementary to Gizzard, since it's one of the larger use cases at Twitter for MySQL. More to come in the future to better support big Gizzard systems!
54.
by jeremycole 15y ago
I think all of the changes pretty much do apply generally, but for us it's easier to go ahead and publish publically to be able to pass these changes upstream, rather than pass them off privately and wait potentially a year or more to get t
55.
by jeremycole 15y ago
It's a fork in the sense that we're developing without an immediate requirement to get MySQL/Oracle to accept our changes. We hope they will accept the changes, of course, but it isn't and can't be a requirement for our own progress.
56.
by jeremycole 15y ago
Pretty hard to make you happy, eh? I agree with you on a purely technical basis, however, this article was written for the MySQL community, was tested (only) on MySQL, and has primarily affected my only on MySQL systems, which I (and the ot
57.
by jeremycole 15y ago
Yes, absolutely. In fact one of the most common longer term referrers for that post is about MongoDB, not MySQL: http://www.mongodb.org/display/DOCS/NUMA
58.
by jeremycole 15y ago
There's also copy-on-write to consider. If you actually had to allocate real memory-backed pages for every allocation a process made, had the right to, but never modified, the size of each process would be a lot larger. For example, if a pr
59.
by jeremycole 15y ago
Well, for the systems in question, they don't necessarily need swap, and they may never actually swap in practice aside from problems such as the NUMA issues described. However, even with swap disabled, the NUMA issues cause problems with
60.
by jeremycole 15y ago
Yes, they are two distinct issues which are somewhat conflated: the actual "swap insanity" and swap in general, and NUMA performance effects. I think for my purposes, the negative effects of NUMA are relatively hidden, so we only see the si

More ›