(Mayank Prasad) A new feature in MySQL Performance Schema is added in DMR 5.7.4. Instrumentation for Prepared statements. This instrumentation gives details of PREPARE and EXECUTE statistics for a prepared statement.

(Hans-Juergen Schoenig) Referring to my previous blog post about the amount of xlog written by PostgreSQL I wanted to clarify what I meant when talking about bypassing the PostgreSQL transaction log.

(Heikki Linnakangas) On some other DBMS’s, bitmap indexes are often used for columns that have only a few distinct values. Boolean columns, status codes and such. Compared to normal B-tree indexes, bitmap indexes are very efficient at packing duplicates.

(Jørgen Løland) I got an interesting question about EXPLAIN and the range access method recently. The person had a query that could be written either with a BETWEEN predicate or an IN predicate, something similar to this:

(Michael Paquier) PostgreSQL 9.4 is coming with more support for triggers, making them now firable on foreign tables. This feature has been introduced by the following commit:

(Ike Walker) The pt-table-sync tool uses the MySQL REPLACE command to rewrite row data on a master database in order to assure consistency between the master and its replicas. The REPLACE command makes a lot of sense for that tool, but it also has the potential to cause problems.

(Todd Farmer) Joro wrote recently about MySQL 5.6.17‘s new support for AES-256 encryption, and it’s a great improvement for people need to encrypt their data at rest. The new session block_encryption_mode variable controls what variant of AES is used, and for backwards compatibility, the default be

(Ike Walker) Today I needed to clone a MySQL user on one of my databases. More precisely, I needed to clone a MySQL grantee in order to allow an existing user to access the database from a different IP address. The process was very easy with the duplicate_grantee() procedure in common_schema.

(ioguix) Most of the PostgreSQL DBAs might know about this large bloat estimate query integrated in check_postgres. It is supposed to compute a rough estimate of the bloat for tables and indexes in a database. As the PostgreSQL wiki page says:

(Chris Calender) I ran into an interesting issue today, while examining some EXPLAIN outputs, and wanted to share the findings, as some of this is undocumented.