В зависимости от вашего опыта postgres и / или sql у вас есть несколько вариантов:
проанализируйте запрос с помощью команды EXPLAIN, чтобы выяснить, не достигли ли вы определенного узкого места. Предупреждение: иногда вывод EXPLAIN может быть трудным для понимания
если вы ожидаете, что большинство или значительная часть геометрий в таблице 1 НЕ пересекают мультиполигон, вы можете попытаться применить предварительное условие к более простому многоугольнику (то есть, разбив мультиполигон на более мелкие части), а затем запустить более тяжелое пересечение мультиполигона только на эти результаты. Смотрите ниже пример.
если и только если ЦП является узким местом (т. е. сервер застрял на пересечениях), я настоятельно рекомендую вам получить больший, более быстрый и более мощный ЦП или арендовать одноразовый экземпляр с высоким ЦП у Amazon EC2 и уничтожить его, когда вы сделанный
Пример запроса для позиции 2:
SELECT DISTINCT ON (st1.userid) st1.userid ,ST_AsText(st1.position), st1.timestamp
FROM (
select userid, position, timestamp from table1
WHERE ST_Intersects ( YOUR_MULTIPOL_BOUNDS_HERE,position)
) as st1
WHERE ST_Intersects ( ST_GeomFromText('a multiypolygon geom goes here',4326),st1.position)
ORDER BY st1.userid, st1.timestamp desc
Для повышения производительности вы также можете временно материализовать подвыбор st1 в виде таблицы, чтобы ее можно было проиндексировать.
@Nicklas правильно указал в комментариях, что пример для предложения 2 не должен помочь. Он прав, но я думаю, что я (частично) тоже прав.
На самом деле, кажется, очень похожий вопрос был задан (и получен ответ) только в ноябре прошлого года на postgis ML:
http://postgis.refractions.net/pipermail/postgis-users/2011-November/031344.html
и оказывается, что предложение состоит в том, чтобы фактически разбить многоугольник, чтобы индекс мог наиболее эффективно отфильтровывать ложные пересечения, которые в противном случае были бы инициированы простой проверкой границы.