B
@keepcoder не, ST_Contains
Size: a a a
2020 August 21
B
ошибка говорит, что разные SRID у объектов
B
ST_GeomFromText('POINT(-71.064544 42.28787)');
P
Вы прислали явно не все содержимое
https://pastebin.com/TNx5y2G9 по больше но тоже не все
P
не исключено, что Вы напоролись на это:
https://github.com/postgrespro/pg_probackup/issues/246
https://github.com/postgrespro/pg_probackup/issues/246
в pg_probackup.conf я могу файлы исключения запихать ?
AF
Ребят, а посоветуйте по архитектуре.
Дано: карта, на карте много ( >1млн) треков (трек это линия, состоящая из точек ХУ). Надо треки показывать по области, которая у клиента отражается.
Сами треки в базе хранить нет смысла - данных излишне много. Треки хранятся в файлах, у каждого трека есть номер.
Думаю в сторону "тайлов" - как в OpenStreetMaps - карту делим на квадратики, и в базе хранить номер квадратика и номер трека.
Вопрос вот какой:
0.
Постгис использовать кажется смысла нет, так как с геометрией по сути не работаю. Хотя может быть я не нашел вкусные фичи у него.
1.
Как лучше хранить связь "номер тайла - номер трека" - делать в самом треке массив тайлов, через которые он проходит, или отдельную табличку Тайл-Трек.
Есть ли разница в производительности?
2. Есть ли у постгреса что-то похожее на выборку по дереву? То есть сказать, что мне нужны все листья вот этого узла.
Хочу адаптировать под QuadKey/QuadTree. Можно конечно использовать строки Like 12214%, но мне кажется это не оч эффективным. Я ошибаюсь?
Дано: карта, на карте много ( >1млн) треков (трек это линия, состоящая из точек ХУ). Надо треки показывать по области, которая у клиента отражается.
Сами треки в базе хранить нет смысла - данных излишне много. Треки хранятся в файлах, у каждого трека есть номер.
Думаю в сторону "тайлов" - как в OpenStreetMaps - карту делим на квадратики, и в базе хранить номер квадратика и номер трека.
Вопрос вот какой:
0.
Постгис использовать кажется смысла нет, так как с геометрией по сути не работаю. Хотя может быть я не нашел вкусные фичи у него.
1.
Как лучше хранить связь "номер тайла - номер трека" - делать в самом треке массив тайлов, через которые он проходит, или отдельную табличку Тайл-Трек.
Есть ли разница в производительности?
2. Есть ли у постгреса что-то похожее на выборку по дереву? То есть сказать, что мне нужны все листья вот этого узла.
Хочу адаптировать под QuadKey/QuadTree. Можно конечно использовать строки Like 12214%, но мне кажется это не оч эффективным. Я ошибаюсь?
YS
Ребят, а посоветуйте по архитектуре.
Дано: карта, на карте много ( >1млн) треков (трек это линия, состоящая из точек ХУ). Надо треки показывать по области, которая у клиента отражается.
Сами треки в базе хранить нет смысла - данных излишне много. Треки хранятся в файлах, у каждого трека есть номер.
Думаю в сторону "тайлов" - как в OpenStreetMaps - карту делим на квадратики, и в базе хранить номер квадратика и номер трека.
Вопрос вот какой:
0.
Постгис использовать кажется смысла нет, так как с геометрией по сути не работаю. Хотя может быть я не нашел вкусные фичи у него.
1.
Как лучше хранить связь "номер тайла - номер трека" - делать в самом треке массив тайлов, через которые он проходит, или отдельную табличку Тайл-Трек.
Есть ли разница в производительности?
2. Есть ли у постгреса что-то похожее на выборку по дереву? То есть сказать, что мне нужны все листья вот этого узла.
Хочу адаптировать под QuadKey/QuadTree. Можно конечно использовать строки Like 12214%, но мне кажется это не оч эффективным. Я ошибаюсь?
Дано: карта, на карте много ( >1млн) треков (трек это линия, состоящая из точек ХУ). Надо треки показывать по области, которая у клиента отражается.
Сами треки в базе хранить нет смысла - данных излишне много. Треки хранятся в файлах, у каждого трека есть номер.
Думаю в сторону "тайлов" - как в OpenStreetMaps - карту делим на квадратики, и в базе хранить номер квадратика и номер трека.
Вопрос вот какой:
0.
Постгис использовать кажется смысла нет, так как с геометрией по сути не работаю. Хотя может быть я не нашел вкусные фичи у него.
1.
Как лучше хранить связь "номер тайла - номер трека" - делать в самом треке массив тайлов, через которые он проходит, или отдельную табличку Тайл-Трек.
Есть ли разница в производительности?
2. Есть ли у постгреса что-то похожее на выборку по дереву? То есть сказать, что мне нужны все листья вот этого узла.
Хочу адаптировать под QuadKey/QuadTree. Можно конечно использовать строки Like 12214%, но мне кажется это не оч эффективным. Я ошибаюсь?
А Вы бы всё равно лучше этот вопрос задали и в чате по postgis (он тут где-то был), на всякий случай — им уж эта тема куда ближе.
GS
https://pastebin.com/TNx5y2G9 по больше но тоже не все
нужен весь файл
AF
Yaroslav спасибо, не знал что он есть отдельный
GS
в pg_probackup.conf я могу файлы исключения запихать ?
зачем?
P
зачем?
ну я подумал что тоже дело в tempах
GS
ну я подумал что тоже дело в tempах
это было предположение
SA
🙏 спасибо
EZ
всем привет. почему могут залипать такие запросы? https://pastebin.com/BagHPCzN обнаружил несколько штук, висящих по 13 часов.
Как я понимаю, это запрос от фреймворка, чтобы построить структуру моделей, и он простой, как 3 копейки. По какой причине он может залипнуть на бесконечность?
Как я понимаю, это запрос от фреймворка, чтобы построить структуру моделей, и он простой, как 3 копейки. По какой причине он может залипнуть на бесконечность?
SS
Коллеги, добрый день. Подскажите такую вещь: есть задача - завести роль, чтобы она не могла работать с данными в таблицах (ни читать, ни писать), но при этом имела доступ к данным о других ролях и (в идеале) видеть логи изменений прав. Как можно это сделать проще всего? Делать Revoke для каждой таблицы во всех БД на сервере - не вариант, сами понимаете.
Повторю свой вопрос
YS
всем привет. почему могут залипать такие запросы? https://pastebin.com/BagHPCzN обнаружил несколько штук, висящих по 13 часов.
Как я понимаю, это запрос от фреймворка, чтобы построить структуру моделей, и он простой, как 3 копейки. По какой причине он может залипнуть на бесконечность?
Как я понимаю, это запрос от фреймворка, чтобы построить структуру моделей, и он простой, как 3 копейки. По какой причине он может залипнуть на бесконечность?
А откуда известно, что они "залипают"?
EZ
Yaroslav Schekin
А откуда известно, что они "залипают"?
Висят 13 часов по pg_stat_activity
EZ
и сейчас висят, ещё не кильнул
YS
Висят 13 часов по pg_stat_activity
А покажите вывод запроса по pg_stat_activity.