Если кто-то, как я, запутался, о каких модемах в статье идёт речь, то это про радиомодемы для мобильной связи, в том числе для нового модного 5G, а не про такие:
Чан Рамён, кажется, по инструкции не заваривать надо, а варить в кастрюле на огне. Если его как обычный доширак использовать, будет гадость. :)
Кстати, в чёрном (Чачжан?) надо сливать воду и и соус добавлять только после этого. :D
Да, там есть ещё limit и offset, если пользователь стал просить других пользователей за пределами кеша, выводится ещё тысяча пользователей из результата.
идти от сортировки по расстоянию, отфильтровывая неподходящих юзеров вложенным запросом
А вот тут моих знаний sql и опыта уже явно не хватает, я просто не представляю, как и куда это сделать.
В мире майнкрафта не получается запускать сервера с плагинами на версиях выше 8: почему-то код сервера, на который можно ставить плагины, требует какую-то дикую интроспекцию, которую Jigsaw запрещает. По крайней мере, мне это так объяснили. :)
Сервис знакомств типа Тиндера и прочих ему подобных.
На самом деле я хочу сделать более защищённый алгоритм поиска расстояния между пользователями, но не хватает времени, всё на более приоритетные задачи уходит.
Более защищённый в том плане, чтобы нельзя было вычислить настоящие координаты другого пользователя, сдвигая свои.
Сейчас расстояние до другого пользователя показывается логарифмически "<1км", «5км», «10км», «25км», ..., но простым округлением. И если сдвигать свои координаты как раз на границе округления 1км-5км, то можно очень даже неплохо триангуляцией узнать приватные данные. Просто округлять в БД координаты WGS84 до четырёх знаков после запятой нехорошо, будет много пользователей с расстоянием в 0 км. Надо почитать на эту тему научных статей.
А, и да, сортируются не все миллион пользователей, а тысяча-другая, которая осталась после фильтрации по всем условиям в WHERE. Хотя если фильтр будет крайне щадящий и пропустит всех пользователей, то, на удивление, всего 2.5 секунды выполняется. Я ожидал худшего. Хотя база на 60-гиговом ssd, external merge быстрый.
Это было риторическое утверждение, без попытки получить помощь. Хотел бы я её – пошёл бы на stackoverflow. :D
Но если нечего делать и задачка интересна, то вот запрос. :)
Типы данных, кмк, и так ясны, но у фильтров и юзеров есть TEXT[], если что.
Там быстродействие не столь важно, результаты кешируются бекендом на пару минут для повторных запросов, но нет предела совершенству. И преждевременной оптимизации.
Я сначала думал, может, баг сайта какой, explain закешировался в браузере. Но зашёл с другого компа – нет, мой план. :D
Так и не смог понять, что надо скормить постгресу, чтобы он sequental scan превратил в index scan. Там поиск по таблице с ~1 млн фейковых записей, и фильтр по колонкам, которые в 99.5% истинны. То есть, возможно, там действительно укорять нечего.
И да, я так понимаю, что cost-попугаи – условная стоимость чтения с диска и выполнения операций, а не предсказанное время. По крайней мере, так документация говорит.
1) У лямбд, как мне кажется, всё же чуть иной случай: чтобы переменная могла быть захвачена, она должна быть либо явно final, либо effectively final. У новых «связываний» финальность появляется от рождения, что чуть отличается от захваченных переменных в лямбдах.
А что произошло с областями видимости вот в этом примере: ↓?
if (!(obj instanceof String str)) {
throw new RuntimeException();
}
System.out.println(str.toLowerCase());
Скомпилировалось. <...>
"Биндинг Связывание паттерна" str вышло за пределы фигурных скобок условного оператора?
То есть он работает иначе, чем try-with-resources, у которого Closeable-переменные, объявленные в круглых скобках, видны только внутри. Это тоже может доставить проблем, чувствую.
То-то я смотрю, что это уже второй пост подряд про транспорт и путешествия: сначала Венеция, теперь самолёты. Но я думал, что это как первоапрельский пост, когда Milfgard и Meklon поменялись постами и мало кто заметил. Думал, сейчас это просто посты для Туту.ру. А тут вот оно что, оказывается.
Кстати, в чёрном (Чачжан?) надо сливать воду и и соус добавлять только после этого. :D
CASE WHEN TRUE THEN...? :)
UPD: Это, похоже, не то, что имелось в виду.
Хотел задействовать типы данных и индексы из постгиса, но не дошли руки. ':)
А вот тут моих знаний sql и опыта уже явно не хватает, я просто не представляю, как и куда это сделать.
Как-то так? Или через CTE?
На самом деле я хочу сделать более защищённый алгоритм поиска расстояния между пользователями, но не хватает времени, всё на более приоритетные задачи уходит.
Более защищённый в том плане, чтобы нельзя было вычислить настоящие координаты другого пользователя, сдвигая свои.
Сейчас расстояние до другого пользователя показывается логарифмически "<1км", «5км», «10км», «25км», ..., но простым округлением. И если сдвигать свои координаты как раз на границе округления 1км-5км, то можно очень даже неплохо триангуляцией узнать приватные данные. Просто округлять в БД координаты WGS84 до четырёх знаков после запятой нехорошо, будет много пользователей с расстоянием в 0 км. Надо почитать на эту тему научных статей.
А, и да, сортируются не все миллион пользователей, а тысяча-другая, которая осталась после фильтрации по всем условиям в WHERE. Хотя если фильтр будет крайне щадящий и пропустит всех пользователей, то, на удивление, всего 2.5 секунды выполняется. Я ожидал худшего. Хотя база на 60-гиговом ssd, external merge быстрый.
Но если нечего делать и задачка интересна, то вот запрос. :)
Типы данных, кмк, и так ясны, но у фильтров и юзеров есть
TEXT[], если что.Там быстродействие не столь важно, результаты кешируются бекендом на пару минут для повторных запросов, но нет предела совершенству. И преждевременной оптимизации.
Так и не смог понять, что надо скормить постгресу, чтобы он sequental scan превратил в index scan. Там поиск по таблице с ~1 млн фейковых записей, и фильтр по колонкам, которые в 99.5% истинны. То есть, возможно, там действительно укорять нечего.
И да, я так понимаю, что cost-попугаи – условная стоимость чтения с диска и выполнения операций, а не предсказанное время. По крайней мере, так документация говорит.
Спасибо за статью. :)
final, либоeffectively final. У новых «связываний» финальность появляется от рождения, что чуть отличается от захваченных переменных в лямбдах.Но это исключительно к слову пришлось. :D
"
БиндингСвязывание паттерна"strвышло за пределы фигурных скобок условного оператора?То есть он работает иначе, чем
try-with-resources, у которогоCloseable-переменные, объявленные в круглых скобках, видны только внутри. Это тоже может доставить проблем, чувствую.Только у них на сайте ничего такого нет. Тоже устарела?.. :/
Да, действительно, каюсь. Глаз зацепился за
101/104, и мозг дописал ANSI сам по аналогии с надписью слева. :/