UNION ... LIMIT в постгресе работает восхитительно:
> EXPLAIN ANALYZE SELECT y FROM test WHERE x = 66 LIMIT 10;
Total runtime: 0.146 ms
> EXPLAIN ANALYZE (SELECT y FROM test WHERE x = 66) UNION (SELECT y FROM test WHERE x = 67) LIMIT 10;
Total runtime: 86.011 ms
Но зато:
> EXPLAIN ANALYZE (SELECT y FROM test WHERE x = 66) UNION ALL (SELECT y FROM test WHERE x = 67) LIMIT 10;
Total runtime: 0.183 ms
УНЯНЯ. У нас есть немножечко инфы
об этом пользователе. Мы знаем, что он понаписал,
порекомендовал и даже и то и другое сразу.
А ещё у нас есть RSS.
EXPLAIN ANALYZE SELECT max(y) FROM test WHERE x = 66;
Total runtime: 0.124 ms
EXPLAIN ANALYZE SELECT max(y) FROM test WHERE x = 66 GROUP BY x;
Total runtime: 29.157 ms
EXPLAIN ANALYZE SELECT max(y) FROM test WHERE x IN (SELECT generate_series (1,1) as x);
Total runtime: 1908.248 ms
ЭСКУЭЛЬ ДЕКЛАРАТИВНЫЕ ЗАПРОСЫ ОПТИМИЗАЦИИ АНАЛИТИЧЕСКИЕ БАЗЫ ДАННЫХ КОКОКОКОКО
Успешно решил задачу кластеризации точек на карте. Благодаря волшебным postgis’овским индексам — за приемлемое время.
Я так понимаю, для любой сложной проблемы есть два решения: обычный — когда ты долго пердолишь в математику, machine learning и еще хуй пойми что, и SQL’ный — когда ты нахуяриваешь еще индексов и O(N²) рассасывается сам собой.
Разработчики PostGIS успешно решили* проблему поиска ближайших соседей путем спонсирования разработчиков PostgreSQL, чтобы те подковыряли двумерные индексы. К сожалению, работает все это только для геометрических объектов, так что на больших расстояниях и на 180-м меридиане придется сосать хуи.
*нашли способ делать запросы за приемлемое время
Цоперайт © 2010-2016 @stiletto.