Toru Maesaka

I’m happy to report that I’ve made some progress in the Query Cache plugin interface that I’ve been working on for Drizzle. The first version of the Query Cache interface definition is now merged to Drizzle’s trunk.

Unfortunately though, you cannot actually write a query cache module for Drizzle yet. I still haven’t implanted the hooks for this interface to Drizzle’s codebase since this requires much more thinking and thorough testing (which is my next milestone for this mini project).

So in other words, I’ve only done the easy part heh. Do let me take this opportunity to introduce the interface that just went in though. Currently the API consists of five functions which looks like this:

 bool (*qcache_try_fetch_and_send)(Session *session, bool transactional);
 bool (*qcache_set)(Session *session, bool transactional);
 bool (*qcache_invalidate_table)(Session *session, bool transactional);
 bool (*qcache_invalidate_db)(Session *session, const char *db_name,
                              bool transactional);
 bool (*qcache_flush)(Session *session);

That’s it! all you need to do is implement the above functions to write a query cache module. Here’s a brief description of what the above functions are intended for (though the name is pretty self-explanatory):

In an ideal world, we would want to do row-based invalidation but this is extremely difficult to do in practice so I will not touch it for now (not sure if I ever will). Instead, I’m planning on taking advantage of primary keys (and possibly the slow query log) and see how that goes before attempting to touch the forbidden fruit… I’m going to keep things dead simple to begin with.

So there you go! a preview of work in progress for one of the many projects that are concerned with modularizing the Drizzle SQL Server. Stay tuned for updates :)

Toru Maesaka drizzle, oss drizzle, oss