Don't forget to index your PostgreSQL foreign keys

One thing that surprised me with PostgreSQL after spending a lot of time with MySQL is that setting foreign key constraints do not automatically generate indexes on those columns. PostgreSQL will implicitly generate indexes for primary keys, but not foreign keys. Since those foreign key columns are precisely the ones you tend to use for joins (either explicitly or implicitly by ORMs like Hibernate), omitting indexes could result in a serious performance hit. Creating indexes is easy enough, whether using the usual SQL command or a Hibernate @Index annotation, but where do you start? Well, the whole point of this blog entry is to point you to another blog entry. It provides a handy query to look for foreign keys that could use indexes, ranked by the ones most likely to need an index. Take a look:

Postgresql: Indexes on Foreign Keys

The language wars and the TIOBE index

Recently, I had a bit of fun by writing a modestly titled blog post arguing in favor of Groovy's adoption over Scala. Among other things, I pointed out that the Indeed.com job trends graphs show much stronger Groovy adoption over Scala. One comment there made the interesting observation that the TIOBE Programming Community Index said precisely the opposite. I did not exactly carry out meticulous research so I confess I did not pay attention to this index when I made that blog post. I thought I'd remedy that oversight in this post.

My Groovy can beat up your Scala

This blog entry is inspired by a blog post I read recently bashing Groovy in favor of Scala. I will opportunistically join in the brawl, contributing my 2 cups of kerosene to the flames by coming out in favor of Groovy.  If you are not interested in the language wars, or if you take this sort of thing way too seriously, feel free to skip this post.

I like Groovy. At my last job, I used Groovy almost exclusively as a "better Java", on top of the typical Spring/Hibernate  stack. I did not use Grails at all, except briefly on a minor project. Even though I had a grand time with Groovy, I never thought of Groovy as the heir to the Java language. A new language will eventually replace Java, I figured, but it would not be Groovy. Whatever the merits or demerits of dynamic typing, I thought, the Java community, platform and class libraries were geared towards static typing. Also, Groovy was too slow. Recent developments have made me question my assumptions.