BTW it sure looks like sequential table scans are being done here in order to calculate the joins...nested-loop style (which grow n^2, or more specifically l*r where l is the number of rows in the left table and r in the right table).
Obviously the key is to keep perm queries at an o(log2(n)) or o(log2(l*r)) or something along those lines if they're to be of any use. o(r*log2(l)) style queries are ok (i.e. row-by-row matching of r with rows selected by a btree index on l).
These views that are being used are very suspect...
