The Power of Subqueries in PostgreSQL

I’m pretty sure everything I’m writing here is true for most other RDBMS, too, but since I’m currently using PostgreSQL I had a chance to test it and show some hard figures here.

The problem to solve is actually a common one and rather easy to solve conceptually: Take attributes from table1 and store them in corresponding rows in table2, using a common id to join them. The straight-forward (and almost direct) translation into SQL is therefore:

UPDATE schema.table1 a 
SET attribute = b.attribute 
FROM schema.table2 b 
WHERE a.id = b.id;

There’s nothing wrong with that statement and it’s going to do exactly what’s intended. Only, it’s not very clever, and hence not very performant. This obviously only matters if your tables are on the bigger end. In my case table1 (the one to update) has 576,806 rows while table2 (the one providing the attribute data) has a whopping 848,664,485 rows. Also I should mention that table2 contains multiple rows for each corresponding row in table1. In that concrete case table2 contains data about point locations (latitude, longitude, timestamp) of people whose attributes (age, gender, etc…) are stored in table1. And there is this one attribute which is wrongly and inefficiently stored with each point location, while it is only dependent on the person and should hence be stored there.

Continue reading →

Running Gephi 0.8.2-beta on MacOS X 10.8.5 Mountain Lion

For my research I’m recently doing a lot of graph and network analysis. So far the tools in ESRI ArcGIS have been sufficient for what I was trying to achieve. I used their Network Analyst Extension and also the Urban Network Analysis toolbox by the City Form Lab at the MIT/SUTD for a more scientific application: the calculation of centrality measures. While these warrant some more in-depth articles in themselves, here I’d like to put a more technical focus on a really annoying problem when using Gephi on a more recent MacOS X system.

Continue reading →