I am not a fan of 'do this - this is best' response to queries like that. Rather: this is what you should try, and choose whichever one suits you better. So, rather than 'natural keys ftw', I am giving him another option to choose from.
You see, in my world, I was able to improve some large dbs performance 10+ times fold, by going for surrogate keys. But in them cases, joins were performed on 2+ varchar PK fields, and the whole thing was crawwwling. So, don't narrow down to one solution because it worked for you. Keep an open book. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
