@polecat Судя по тому, что он высирает не первый день - он хранит треки каких-то объектов. Скорей всего делает какой-то ДИСПЕТЧЕРСКИЙ ЦЕНТР, куда собирается информация от машин со шпутниковыми приемниками. Предположения: таксисты, менты, мчс.

@polecat > ты чот наёбываешь, не верю. > наверняка не тот костыль взял просто. Да вот нихуя, работает. 7000 записей в базе: irb(main):014:0> Route.count (3.6ms) SELECT COUNT(*) FROM "routes" => 7174 Выбрать 100 ближайших роутов: irb(main):015:0> Route.near(Route.find(10), 300000).limit(100) Route Load (0.9ms) SELECT "routes".* FROM "routes" WHERE "routes"."id" = $1 LIMIT 1 [["id", 10]] Route Load (23.5ms) SELECT "routes".* FROM "routes" ORDER BY routes.center_point_geom <-> (SELECT center_point_geom FROM routes WHERE id = 10) LIMIT 100 => #<ActiveRecord::Relation [#<Route id: 10, gpx_id: nil, title: "7", description: nil, center_point_geog: #<RGeo::Cartesian::PointImpl:0x36d01fc "POINT (55.885411 28.722457)">, created_at: "2014-08-27 19:02:18", updated_at: "2014-08-27 19:02:18", center_point_geom: #<RGeo::Cartesian::PointImpl:0x36d4734 "POINT (55.885411 28.722457)">>, #<Route id: 5150, gpx_id: <...> 23.5ms. Прошу прощения за ruby. > алсо нахуя тебе PostGIS? У оратора выше очень забавная теория, но на самом деле я просто слишком обстоятельно подошел к реализации на сайте идеи «хуита возле вас».

@polecat > бля, тупой штоле. пердоль через яндекс/гуглокарты там всё само же. Что там само? Они предоставляют тебе БД, куда ты кладешь свои объектики, и функцию «показать объектики рядом»? Облачно! Покажи, где это. > я не понял что я должен был понять из етого рубивысера. Из этого рубивысера ты бы мог понять, что распердоливание 100 ближайших хуевин среди 7000 с сортировкой по возрастанию расстояния проходит за 23 миллисекунды. > алсо пруф что для корректной формулы нельзя индекс подпердолить. А как ты его подпердолишь, если там расстояние каждый раз на ебучей сфере высчитывается?

@polecat > треки в постгресе не круто хранить потому что он их сжимать не умеет, насколько я знаю. Я даже не знаю, что на это ответить.

@polecat > вообще ни о чём инфа. могло и брутфорсом квадратичным ето сделать. Очевидно, ты тупой. > надо подумать. на торе например тривиально делается. Ну ты подумай, подумай. Серьезно.

@polecat Я добавлю 1 (одну) запись, и время должно увеличиться в два раза. Так ведь?

@polecat Пиздец какой.

Бартунов говорил, что у него есть какие-то готовые (но не внесённые в постгре) улучшения для задачи вида "найти в области объекты с определённым свойством" (квартиры в Москве дешевле 100500 миллионов), но для внесения в постгре надо много трахаться, а спонсоров нет. Один успешный микроблоггер спрашивал насчёт спонсирования, может быть, что-нибудь получится. inb4 "и чо?"

@ckorzhik Я нихуя не понял. Он придумал where price < 100 500 000 000 ?

@ckorzhik Кстати, именно он распердолил индекс для knn.

@komar всё началось с того, что ему сказали, что where price < 100 500 000 000 работает медленно, он сказал, что у него уже есть готовые патчи, но в апстрим их надо толкать долго (если не ошибаюсь, у него по этому поводу есть истории про jsonb).

@ckorzhik Блядь, как оно может работать медленно?

@komar когда запускаешь вместе с nearest neighbours. Суть в том, что в районах, где объектов мало, работает норм, а на Москве как раз тормозит. //я не настоящий сварщик, лучше спросить у него самого или у netneladno

@ckorzhik А, понял.

@polecat Ну я могу аккуратно подойти. Чем трек отличается от любых других данных?

@polecat Да, все же долбоеб.

@polecat Если ты треки собрался как файлы хранить — пожми их чем угодно и храни где угодно. Я так и делаю, например.

@polecat Что за хуйню ты несешь?