@korotovskii а исходные данные у тебя как лежат?

Это к Денису вопрос )

Пардон. @den1970 Если данные можно положить в базу в 3857 (очень рекомендую сразу так сделать), и искать в ней. То индекс gist по колонке и <-> в помощь. Если, как в примере запроса 4326, то вызов st_transform всё съест и тогда лучше ::geography <-> ::geography делать.

CREATE INDEX "user_point_index_st" ON "user" USING GIST (st_transform(st_setsrid(st_point(point[1], point[0]), 4326), '+proj=hammer')); CREATE INDEX "task_point_index_st" ON "task" USING GIST (st_transform(st_setsrid(st_point(point[1], point[0]), 4326), '+proj=hammer'));

Этого достаточно чтобы работало по индексу.

но... зачем?

при запросе тогда будет поиск по индексу, а потом перевычисление значения. st_transform не дешёвая операция с тригономерией

а дистанция в 3857 это корень суммы квадратов координат

В таком случае мне вообще достаточно a <-> б Мне ведь не принципиально в километрах результат

Но оказалось недостаточно

нет. Фокус: [local]=# SELECT st_setsrid(st_point(1, 0), 4326) <-> st_setsrid(st_point(2, 0), 4326); ┌──────────┐ │ ?column? │ ├──────────┤ │ 1 │ └──────────┘ (1 row) Time: 0,512 ms [local] # SELECT st_setsrid(st_point(1, 0), 4326) <-> st_setsrid(st_point(359, 0), 4326); ┌──────────┐ │ ?column? │ ├──────────┤ │ 358 │ └──────────┘

Это мой хлеб :)

Так и подмывает спросить. "Ты питаешься геоданными?" ))

Так и подмывает спросить. "Ты питаешься геоданными?" ))

Если предложить ему геоданные хорошего качества и под правильной лицензией, то он вполне их переработает ;)

через lon:0 в лоб переходить не получается. А геойд, сцукко, круглый.

Еще вопрос. Насколько правильно хранить фото в БД? Понимаю что звучит чуть придурковато. Но вот 1c хранит/хранило фото БД. Этому есть оправдание? Как это применимо в postgres?

Нет этому оправданий

Лучше не делать, а то будешь гореть в аду

Это снимает боль по менеджменту хранилища (на самом деле переносит его на БД) и удваивает передачу данных при чтении (вместо диск -> сеть получается диск -> приложение -> сеть)

В общем, это от жировых масс, обволакивающих чересчур ленивый мозг

Ясно. Запомню

Я просто говорю как тот, у кого есть хостинг картинок

И там была такая схема ?

(надеюсь я не буду гореть в аду, т.к. я уже исправил это)

Аминь

Я просто говорю как тот, у кого есть хостинг картинок

То есть исходник в базе хранил а статику на сервере?

Нет, все в базе лежало

Ох....

Ну кроме css и js да

Если ты об этом

Встречал я какие то расширения для работы с фото для postgres. и это тоже путает.

Получается есть не только неправильные структуры, так еще и для них расширения написаны

Очереди тоже есть (mbus) — не поддавайся на провакацию.

Очереди тоже есть (mbus) — не поддавайся на провакацию.

Вот ты хорошо предупредил. Я так поглядывал и только из-за недостатка времени не добрался до этого

Получается есть не только неправильные структуры, так еще и для них расширения написаны

мы сейчас говорим про веб-приложения, все кейсы под это подгонять было бы неправильно

а в чём различие? В передаче файла?

не могу сходу придумать кейс, где это было бы оправдано и не факт, что такой существует, но это не обязательно плохая практика вообще во всех случаях

Хотя Skype вот использует mbus (типа)

Или pgq?

Ок, раз ты готов отвечать. "WITH COMPRESSION" юзал?

Не суть, одного рода поделие короче

Это мне вопрос?

ну обоим уж :)

а можно и каждому 821 участнику :)

Я хранил картинки в базе кгда был молодой^W^W у меня был MySQL

Так что это был дабл факап.

Ок, раз ты готов отвечать. "WITH COMPRESSION" юзал?

кейс: есть 1,5 гигабайта скачанных исходных страниц, хранимых в postgres в виде base_64(gzip())

кейс: есть 1,5 гигабайта скачанных исходных страниц, хранимых в postgres в виде base_64(gzip())

Так вот, мне кажется я где-то костыль делаю и можно обойтись простым сжатием на уровне БД

или нет?

ну и логи хранить можно так

Просто если верить oracle (провожу параллель) то эта операция как раз и нужна для того чтобы текстовые данные ужимались

есть ли в этом подводные камни?

Ну у оракла вы имеете ввиду сжатие CLOB в secure file?

Вроде в постгре аналога нет пока (или я о нем не слышал)

неужели никто не сделал fdw для хранения картинок на fs? :)

https://wiki.postgresql.org/wiki/Foreign_data_wrappers

Ну можно nosql для этих целей - они местами лучше фс

Про кластерные индексы же ведь речь?первичный ключ не обязан быть кластерным.Более того,это скорее всего от безысходности он такой.Когда данные вставляются хаотично в этом тоже есть плюс:можно не ждать когда закончится предыдущая вставка в голову,если ты добавляешь в середину.Да,в таблице появляется много полупустых страниц и выше накладные расходы,когда нужно разделить страницу.Но зато все нужные тебе данные окажутся на одной странице,ну или на соседних,а не разбросаны по всему базе.Правда не знаю что из этого подходит к postgres.Ну и за var не скажу,по-моему,уж лучше фиксированный размер иметь

Доклад был на dump-2015 вродь, там Армин Роначер расказывал, что они хранят сами blob’ы картинок в постгресе как значение это для cdn вродь

вот у этого трансляции не будет? https://www.meetup.com/postgresqlrussia/events/229372553/

Еще вопрос. Насколько правильно хранить фото в БД? Понимаю что звучит чуть придурковато. Но вот 1c хранит/хранило фото БД. Этому есть оправдание? Как это применимо в postgres?

у нас огромное количество маленьких фото(64х64) хранятся в базе, говорят что так быстрее работает

Ну можно nosql для этих целей - они местами лучше фс

Seriously?

у нас огромное количество маленьких фото(64х64) хранятся в базе, говорят что так быстрее работает

Вы так делаете, потому что кто-то в интернете сказал, что это будет быстрее?

нет, так разработчики сделали

большие фото и прочее - на диске, мелкие в базе

я думаю, стоит развеять их заблуждения по поводу скорости

Всем доброго дня! Помогите разобраться. Есть две таблицы: T1 и T2. Запрос такой: SELECT T1.f_service, T1.f_template, T2.is_inherit, T2.name FROM T1 JOIN T2 ON T2.f_template = T1.f_template AND COALESCE(T2.f_client,3) = 3 AND T2.stat = 0 WHERE T1.f_object = 2 AND T1.stat = 0 И он уходит в Nested Loop: "Nested Loop (cost=0.00..6.29 rows=1 width=50)" " Join Filter: (T2.f_template = T1.f_template)" " -> Seq Scan on T2 (cost=0.00..1.14 rows=1 width=42)" " Filter: (((stat)::smallint = 0) AND (COALESCE(f_client, '3'::bigint) = 3))" " -> Seq Scan on T1 (cost=0.00..5.09 rows=5 width=16)" " Filter: ((f_object = 2) AND ((stat)::smallint = 0))" При этом причина - в фильтре T1.f_object = 2. Если его убрать - то Hash Join...

ну наверное его статистика говорит, что после фильтрации T1.f_object = 2 будет 5 строк а после фильтрации T2 будет вообще 1

так что Nested Loop тут как бы неплох, ибо не нужно создавать хэш структуры промежуточные и все такое

Поддерживаю, надо смотреть на реальных объемах данных.

Seriously?

Масштабирование не?

ну да, распределенных файловых систем не существует

ну да, распределенных файловых систем не существует

На них возникают вопросы к скорости. В каждом конкретном случае подойдёт разное решение. Но в общем случае распределённую фс сложнее заточить под поиск по определенному ключу, чем тот же couchbase

файловая система - это специфичный вид базы данных, с основной фишкой про seek() внутри записи

файловая система - это специфичный вид базы данных, с основной фишкой про seek() внутри записи

Часто ли вы меняете часть картинки?

Опять я холиварище закинул )

я к тому, что часто вместо файловой системы достаточно объектного хранилища

На них возникают вопросы к скорости. В каждом конкретном случае подойдёт разное решение. Но в общем случае распределённую фс сложнее заточить под поиск по определенному ключу, чем тот же couchbase

база на фс будет быстрей фс? серьезно?

так что Nested Loop тут как бы неплох, ибо не нужно создавать хэш структуры промежуточные и все такое

Спасибо за наводку. В целом это уже реальный набор данных ))) И принципиально много строк после фильтрации быть не может... Максимуму 100-200

база на фс будет быстрей фс? серьезно?

да

listdir на мнoгих ФС не оптимизирован

база на фс будет быстрей фс? серьезно?

Ну вы определитесь про какую файловую систему вы говорите. Распределённая фс - с большой вероятностью медленнее шардированной БД

из-за чего народ городит вложенные каталоги по префиксам

так то и по direct i/o можно ходить... фс еще какие-то выдумали ;)

после mmap от ФС мало что остаётся

listdir на мнoгих ФС не оптимизирован

мы сейчас вроде говорим про статику и де-факто k/v говорим

Ну вы определитесь про какую файловую систему вы говорите. Распределённая фс - с большой вероятностью медленнее шардированной БД

а распределенная фс не шардируется?

а, из живых примеров

Спасибо за наводку. В целом это уже реальный набор данных ))) И принципиально много строк после фильтрации быть не может... Максимуму 100-200

вы проверьте, что статистика по таблицам собрана и обновлена

тайлы карт миллионами пакуют в sqlite-базы

и называют это стандартом mbtiles

и оно быстрее, чем фс

и нет страданий с закончившимися инодами или tail packing

и оно быстрее, чем фс

там придется сильно попотеть, чтобы вытащить всякие няшки типа zero copy

которые во всех примерах со статикой невозможны без большого геморроя при пропуске этой статики через приложение

Памятка для презентаций: Никогда не вставляйте в презентацию видео с YouTube. Конференц Wi-Fi упадет именно в тот момент, когда две сотни глаз будут ждать его загрузки

Эм, а локально положить?