The SQL that Mondrian generates is, until now, different than the SQL that most people would write by hand. Most people don't use spaces or punctuation in table and column names, and don't enclose identifiers in quotation marks when writing SQL DDL, DML or queries. Mondrian, on the other hand, religiously quotes every identifier, whether it needs it or not.

The two styles are not compatible because on many databases (Oracle is one example) unquoted identifiers are implicitly converted to upper-case. If you use lower-case table and column names in Mondrian's schema, they will not match the upper-case identifiers created during DDL.

For instance, if you create a table in Oracle using

CREATE TABLE emp (
  empno INTEGER,
  ename VARCHAR2(30),
  deptno INTEGER);

then Oracle creates a table called EMP with columns EMPNO, ENAME and DEPTNO. When you query it …

My colleague who is a Windows guru taught me how to do very basic things with the Windows profiler. While this stuff is primitive, the sad truth is that many people don’t know even this little about Windows, me including. I’ll keep the hints here, and hopefully will learn more with time.

• Use RelWithDebInfo builds, Debug build will screw the picture, it will tell you _db_enter is the most expensive function;

• Start mysqld;

• Use x64 VS command prompt:

Start => All Programs => MS Visual Studio 2010 => Visual Studio Tools => Visual Studio x64 Win64 command prompt

• Set _NT_SYMBOL_PATH to the package bin directory, so mysqld.pdb can be found, and start the IDE:

set _NT_SYMBOL_PATH=... && devenv.exe

• In the VS command prompt, run

vsperfcmd /start:sample …

Save energy by OS-driven DRAM refresh:

Had the same idea… they’ve been faster :)

Recent Tips and News on Java, Java EE 6, GlassFish & more :

OK, to begin with, I'd really like to try MySQL Cluster as a Key-Value Store. Yes, I have already recognized that MySQL Cluster stores variable length data in fixed length format. And someone should think about how good an idea this really is, in my mind it's just as mindbogglingly efficient, modern and start as storing data on punched cards. Which I assume how the MySQL Cluster sourcecode is managed.

yes, I really dislike the idea of fixed length strings, and more on this later. But think now, I have 2 fields defined as VARCHAR(256) and this is a Web application, then how much space will be allocated on disk for MySQL Clsuter? As many bytes are there are in the string r 256 bytes? Neither actually, this is a web-app, and I know it comes as a surprise to some of you, but Unicode is here to stay, and UTF-8 is way to go. And MySQL assumes that no one will use more than a 3-byte Unicode character (which is an incorrect assummpion, but I …

Since the new MySQL Pacemaker resource agent supporting PRM is now included in version 3.9.3 of the official Pacemaker resource agents package and things have stabilized a bit, I have been able to write some documentation. I wrote a first draft of the PRM documentation that is likely far from perfect, but I hope it will be useful and improve rapidly. The PRM documentation is available here. Comments and suggestions are welcome but please use the linux-ha or the pacemaker mailing lists instead of replying to the blog post directly.

The binlog sync contention was a problem from a long date in MySQL.. Well, it was less visible few years ago until MySQL performance was quite limited even without binlog enabled ;-)) However, with all latest performance improvement came with MySQL 5.5 and now with 5.6, it became unacceptable to see all these excellent goodies simply killed once a user enabling binlog..

Good news -- the latest MySQL 5.6 labs release is coming with freshly released Binlog Group Commit which is greatly solving this issue. You may find all details about in the Mat's article, while my intention in this post is just to extend little bit already presented benchmark results..

Well, the true performance problem with MySQL binlog is coming not really when it's enabled, but since the "sync_binlog" is set to 1 (means flush binlog to disk …

This article describes how I tuned MariaDB to give the best write throughput with SSD based storage.

When you have a write-heavy application writing into InnoDB, you will probably experience the InnoDB Checkpoint Blues. The effect manifests as stalls – short periods of time where the troughput falls to zero and I/O activity goes crazy. The phenomenon is well known and described i.e. here. More background about checkpointing can be found …

A few days ago MariaDB, MySQL and Percona all three released new versions of the 5.5 server. So I decided it’s time to run sysbench once more and compare the OLTP performance. The test candidates are:

• MariaDB-5.5.24, using either XtraDB (default) or InnoDB
• MySQL-5.5.25
• Percona Server 5.5.24-26.0

For the benchmarks I used our trusty old pitbull machine which has 24 cpu cores, 24G of RAM and a nice RAID-0 composed of 3 SAS SSD.

The benchmark was sysbench-0.5 multi-table OLTP, using 8 tables with total 10G of data. InnoDB buffer pool was 16G, InnoDB log group capacity 4G (the maximum for MySQL). The mysqld process was constrained to 16 cores, sysbench to the other 8.

The only nonstandard tuning was for I/O scalability: innodb_io_capacity = 20000 and innodb_flush_neighbor_pages = none (for Percona Server and MariaDB/XtraDB). See …

This article describes how I tuned MariaDB to give the best write throughput with SSD based storage.

When you have a write-heavy application writing into InnoDB, you will probably experience the InnoDB Checkpoint Blues. The effect manifests as stalls – short periods of time where the troughput falls to zero and I/O activity goes crazy. The phenomenon is well known and described i.e. here. More background about checkpointing can be found …