The memory usage of a join has many more variables than the size of the joined field (in some cases it might not matter at all as long as that field is not incl

The memory usage of a join has many more variables than the size of the joined field (in some cases it might not matter at all as long as that field is not included in the result set) so I would not say that joining on a short string is that much more predictable than joining on a possibly long string. What matters the most is what the query actually does, what the data looks like, and what indexes you have. Joins are usually implemented in one of these three ways, and the planner can select which one to use depending on the query and table statistics: 1. Hash join: Build a hash table of all the joined fields of set 1 and then traverse the rows of set 2 looking them up in the hash table. 2. Merge join: Sort both sets of rows and merge them. With the right indexes you may not even need to sort anything, just traverse in index order. 3. Nested loop join: For every tow in set 1 find matching entries in set 2.