As noted in a previous post, I have released MyQuery 3.1. A user found a nasty little unnecessary bug that caused a crash in the profile dialog, when the Group by status checkbox was clicked when there was no data. This has now been fixed and a 3.1.1 version it available on Sourceforge for download.
/Karlsson
I am Anders Karlsson, and I have been working in the RDBMS industry for many, possibly too many, years. In this blog, I write about my thoughts on RDBMS technology, happenings and industry, and also on any wild ideas around that I might think up after a few beers.
Thursday, September 10, 2009
Wednesday, September 9, 2009
Released: MyQuery 3.1 Beta
MyQuery 3.1 is now ready for download from Sourceforge! There is a bunch of cool features, but the theme was Convenience and DBA Features. On top of this, UTF-8 support has also been added, not in a terribly advanced way, but it should work for most needs.
Among the new features are:
There are three different download files available from Sourceforge as above:
Cheers
/Karlsson
Among the new features are:
- Events dialog to manage MySQL events
- Much enhanced Drag-and-drop support. Drag a tables, index or column from the dictionary window to the editor, and the CREATE statement will be pasted for you.
- SQL variables dialog, with helptext and manual links for most variables.
- SQL Profiling support, including the ability to compare the profile of two different queries.
There are three different download files available from Sourceforge as above:
- A pdf - Documentation.
- MyQuery_3_1_setup.zip - The binary installer for Windows, including a setup program and the documentation pdf.
- MyQuery_3_1.zip - The full sourcecode.
- Support for the InnoDB pluging INFORMATION_SCHEMA tables, including a lock graph.
- Support for NDB objects, such as tablespaces and stuff.
- A few wizards.
- Support for other storage engine specific features.
- User and authorization management dialogs.
Cheers
/Karlsson
Tuesday, September 8, 2009
SSD disks... Bah!
SSD disks seems to be the hot and cool new disk technology. And I have to admit I don't understand why this is so hot. I think it's useful alright, but really, putting an ancient block level interface that dates back to the 1970's or so, to access a persistent, random access and fast media just seems backwards to me. Why? Because by doing this, we retain compatability with that old block-level access of course, but we loose performance and we loose random access.Properly used, flash based memory should provide fast, persistent random-access memory, that is the promise of the technology, right? Any many seems copncered with what filesystem to use on SSD disks? Hey, com on, it's just like RAM! Slower, yes, by persistent. I don't need blcok level access, it doesn't help and the interfaces are inherently slow. And if the underlying media is random access, why, for heavens sake why?
Yes, I know there are a few issues to solve with Flash storage still, and that it will eventually "burn-out", but it seems like those problems are being worked on and a much smaller than what they used to be.
No, I don't want an SSD optimized filesystem, but I don't want to access flash over a serialized stoarge anyway! Can we instead have a standardized means of accessing flash as it should be accessed: Random access! Persistent! SSD is just a stop-gap solution for the real thing, in my mind. And yes, I understand that things take a while to develop. And yes, I understand that compatability with older equipment, hardware and OSes are a good thing. But the real McCoy here is, hey, you gessed it, a means of random access to flash! The issues with erasing flash should also be possible to solve, probably in software. So we probably need a software layer here.
Maybe we should be virtualizing RAM to flash. Maybe we should add some new interface for a "persistent malloc". Maybe applications should not need to be Flash aware (I think they should, as only the application knows what data needs persistence and what does not). But in any case, applications should be able to access Flash as true Random access, although I do understand that there are limites to this in terms of erasing. That is the problem I want fixed, not a new filesystem!
In a database, putting the transaction log on flash should be great, for example, but there are many more uses. Can we see a Flash based MySQL Storage Engine. No, not one optimized for SSD, one that accesses Flash directly!
But SSD's should, in my mind, should eventually be gone. Which is not the same thing as it will happen. We used the silly IDE interface for way too long, for example.
/Karlsson
Yes, I know there are a few issues to solve with Flash storage still, and that it will eventually "burn-out", but it seems like those problems are being worked on and a much smaller than what they used to be.
No, I don't want an SSD optimized filesystem, but I don't want to access flash over a serialized stoarge anyway! Can we instead have a standardized means of accessing flash as it should be accessed: Random access! Persistent! SSD is just a stop-gap solution for the real thing, in my mind. And yes, I understand that things take a while to develop. And yes, I understand that compatability with older equipment, hardware and OSes are a good thing. But the real McCoy here is, hey, you gessed it, a means of random access to flash! The issues with erasing flash should also be possible to solve, probably in software. So we probably need a software layer here.
Maybe we should be virtualizing RAM to flash. Maybe we should add some new interface for a "persistent malloc". Maybe applications should not need to be Flash aware (I think they should, as only the application knows what data needs persistence and what does not). But in any case, applications should be able to access Flash as true Random access, although I do understand that there are limites to this in terms of erasing. That is the problem I want fixed, not a new filesystem!
In a database, putting the transaction log on flash should be great, for example, but there are many more uses. Can we see a Flash based MySQL Storage Engine. No, not one optimized for SSD, one that accesses Flash directly!
But SSD's should, in my mind, should eventually be gone. Which is not the same thing as it will happen. We used the silly IDE interface for way too long, for example.
/Karlsson
Subscribe to:
Posts (Atom)