What if you could turn
thousands of lines of code into
simple queries?

If you don’t know about ClusterSSH, it’s a project that builds on M-x term and ssh to offer a nice and simple way to open remote terminals. It’s available in ELPA and developed at github cssh repository. The default binding is C-= and asks for the name of the server to connect to, in the minibuffer, with completion. The host list used for the completion comes from tramp and is pretty complete, all the more if you’ve setup ~/.


I wrote a book!


Those are my two all times favorite Open Source Software. Or Free Software in the GNU sense of the world, as both the BSD and the GPL are labeled free there. Even if I prefer the The Debian Free Software Guidelines as a global definition and the WTFPL license. But that’s a digression. I think that Emacs and PostgreSQL do share a lot in common. I’d begin with the documentation, which quality is amazing for both projects.


Background writers

There’s currently a thread on hackers about bg worker: overview and a series of 6 patches. Thanks a lot Markus! This is all about generalizing a concept already in use in the autovacuum process, where you have an independent subsystem that require having an autonomous daemon running and able to start its own workers. I’ve been advocating about generalizing this concept for awhile already, in order to have postmaster able to communicate to subsystems when to shut down and start and reload, etc.


Logs analysis

Nowadays to analyze logs and provide insights, the more common tool to use is pgfouine, which does an excellent job. But there has been some improvements in logs capabilities that we’re not benefiting from yet, and I’m thinking about the CSV log format. So the idea would be to turn pgfouine into a set of SQL queries against the logs themselves once imported into the database. Wait. What about having our next PostgreSQL version, which is meant (I believe) to include CSV support in SQL/MED, to directly expose its logs as a system view?


There’s a big trend nowadays about using column storage as opposed to what PostgreSQL is doing, which would be row storage. The difference is that if you have the same column value in a lot of rows, you could get to a point where you have this value only once in the underlying storage file. That means high compression. Then you tweak the executor to be able to load this value only once, not once per row, and you win another huge source of data traffic (often enough, from disk).

Dimitri Fontaine

PostgreSQL Major Contributor

Open Source Software Engineer

France