Упростил реальный кейс до двух таблиц (объекты и связи между объектами) и функции, которая по id объекта возвращает id привязанного к нему объекта. Суть в использовании именно функции для джойна, а не прямом джойне таблиц.
Заполняем таблицы небольшим количеством данных — в примере всего 500 объектов, половина из которых имеет связь. http://sqlfiddle.com/#!15/4881e1/6 и делаем два запроса с джойном функции:

/* (SLOW) */
-- функция вызывается 500*500 раз, после чего делается джойн вложенным циклом
-- Execution Time: 5242ms
explain analyze select obj.id, ot.id
from toobject obj   
left join toobject ot on ot.id = to_getidref(obj.id);

/* (FAST) */
-- функция вызывается 500 раз в сабквери, после чего делается хеш джойн
-- Execution Time: 19ms
explain analyze select obj.id, ot.id
from toobject obj   
left join toobject ot on ot.id = (select to_getidref(obj.id));

UUID Primary Keys in PostgreSQL

This makes sense due to the random probability distribution of the keys, it should be fragemented. This fragmentation however is not so good for efficiency of the database system itself. In order to gain the benefits of using UUID primary keys with lower keyspace fragmentation perhaps Drew points out that it is better to use uuid_generate_v1mc() from the uuid-ossp extension because underneath it is using a time based seq algorithm which you can read about in the postgresql documentation.

http://postgresql.leopard.in.ua/ норм книжка?