добрый день

так оно и есть, говорю как разработчик postgres, у postgres вообще проблемы с запросами у которых больше 8 join

поэтому давайте делать БД чтобы не было больше 8 таблиц? не кажется это бредом?

поэтому давайте делать БД чтобы не было больше 8 таблиц? не кажется это бредом?

при чём тут колличество таблиц?

почтенные господа дба, подскажите, где есть годные калькуляторы, которые посчитают все параметры postgres.conf чтобы СУБД использовала максимальный размер оперативной памяти?

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

при чём тут колличество таблиц?

про 8 join'ов кто написал? при том и таблицы

почтенные господа дба, подскажите, где есть годные калькуляторы, которые посчитают все параметры postgres.conf чтобы СУБД использовала максимальный размер оперативной памяти?

а вам для чего?

про 8 join'ов кто написал? при том и таблицы

8 join в запросе! в БД таблиц может быть хоть 1000

а вам для чего?

вопрос из разряда "а с какой целью интересуешься" :)

8 join в запросе! в БД таблиц может быть хоть 1000

сделать таблицу фактов?

с целью оптимизации использования памяти как раз

вопрос из разряда "а с какой целью интересуешься" :)

ну типо того, просто там разная память есть

меня смущает, что используется только половина оперативки

почтенные господа дба, подскажите, где есть годные калькуляторы, которые посчитают все параметры postgres.conf чтобы СУБД использовала максимальный размер оперативной памяти?

http://postgresql.leopard.in.ua/html/#настройка-сервера

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

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

с целью оптимизации использования памяти как раз

если для создания индексов то это work_mem если в целом тот шареная память желательно половину от оперативки если это linux

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

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

потому что все тупые. мы уже поняли.

я такого не писал

в споре рождается истинна

меня смущает, что используется только половина оперативки

половину и надо, так как postgres не использует прямой доступ к диску и работает через дисковый кеш ОС.

а, т.е. всё норм

но пока никто не обосновал, кроме фразы "8 join'ов в запросе" почему избыточность данных и повышение процесса записи - это выгодно

я умываю руки

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

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

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

такое часто только в сборе аналитики в веб-проектах, но это не панацея

но пока никто не обосновал, кроме фразы "8 join'ов в запросе" почему избыточность данных и повышение процесса записи - это выгодно

за счёт этого вы ускоряете причём в разы выборку по нужному вам запроссу. Если вы очень редко пишете и часто читаете то вот и ОНО.

за счёт этого вы ускоряете причём в разы выборку по нужному вам запроссу. Если вы очень редко пишете и часто читаете то вот и ОНО.

Если мы редко пишем, но часто читаем, то мы делаем, чаще пишем, читаем так же

за счёт этого вы ускоряете причём в разы выборку по нужному вам запроссу. Если вы очень редко пишете и часто читаете то вот и ОНО.

Чем матвьювы плохи для подобных случаев?

где профит?

Чем матвьювы плохи для подобных случаев?

Насколько понимаю, это одно и то же, только ответственность генерации висит на приложении, а не на бд. Ну и возможности чуть пошире, если часть данных берется из стороннего источника, c matview могут быть проблемы.

такое часто только в сборе аналитики в веб-проектах, но это не панацея

ну вот конкретно мой вариант - у меня есть many to many где 500 000 с одной стороны, 70 000 с другой и 2 500 000 связей между ними. Постоянно надо искать что то в первой стороне (таблице) по данным из второй таблицы. join или select 1 карйне медленны, зато int array + GiST индекс + query int даёт десятикратный прирост производительности.

если для создания индексов то это work_mem если в целом тот шареная память желательно половину от оперативки если это linux

половину от оперативки - это слишком, зачем одно и то же держать и в файловом кэше и в шаред?

https://wiki.postgresql.org/wiki/Performance_Optimization

половину от оперативки - это слишком, зачем одно и то же держать и в файловом кэше и в шаред?

quicksort еще в этой памяти, но 50% это перебор конечно

ну вот конкретно мой вариант - у меня есть many to many где 500 000 с одной стороны, 70 000 с другой и 2 500 000 связей между ними. Постоянно надо искать что то в первой стороне (таблице) по данным из второй таблицы. join или select 1 карйне медленны, зато int array + GiST индекс + query int даёт десятикратный прирост производительности.

many to many? Без нормализации? Месье знает толк в извращениях...

половину от оперативки - это слишком, зачем одно и то же держать и в файловом кэше и в шаред?

что бы быстрее работало т.к. шареная память в данном случае быстрее чем дисковый кеш

many to many? Без нормализации? Месье знает толк в извращениях...

нормализация есть у него, просто данные продублированны в денормализованном виде

если я правильно понял

many to many? Без нормализации? Месье знает толк в извращениях...

ну вот потом сделал

если я правильно понял

всё верно

@stalkerg если настолько редкая вставка, то почему не матвью? Не дешевле будет?

Чем матвьювы плохи для подобных случаев?

Если взять тот проект, с которым сейчас кочевряжусь: данные хранятся в виде стрима событий над сущностью в json (event sourcing), и фактически БД не может сама полностью собрать сущность - это может только приложение. У этих же сущностей есть поле metadata, в котором лежит произвольный объект, по ключам и значениям которого надо искать. Приложение при каждом апдейте сущности не только добавляет событие в стрим, но и обновляет все связанные таблицы, по которым производится поиск.

@etkee, без словесной постановки задачи мне сказать в принципе нечего. Но упоминание связки json+СУБД вводит меня в уныние и безрадостность, ибо "модно, задорно, молодёжно". :( А гнаться за модой, задором и молодёжностью - занятие зело бесперспективное.

Простите за офтоп, но как же режет глаз читать все эти ??⏳??Super/Duper_Puper в нике каждый раз в сообщении.

Простите за офтоп, но как же режет глаз читать все эти ??⏳??Super/Duper_Puper в нике каждый раз в сообщении.

СувегРипк же :)

Да хотел прочитать лог дискуссии но уже через 30 секунд начал дергаться глаз.

спор не о чем, РСУБД пытаются использовать как денормализованное хранилище.

и говорят что это "нормально"

шутка про то, что "ненормально" уже заложено в слово "денормализация"

Матвью - вот она "правильная" форма денормализации )

Матвью - вот она "правильная" форма денормализации )

Вот я и пытаюсь понять, почему эта форма денормализации не используется.

Вот я и пытаюсь понять, почему эта форма денормализации не используется.

потому реализация не позволяет удобно использовать?

> и фактически БД не может сама полностью собрать сущность - это может только приложение вот основное

денормализованная таблица не может собраться лишь из других таблиц путем SQL преобразований.

денормализованная таблица не может собраться лишь из других таблиц путем SQL преобразований.

А функции на pg perl там или прочих языках нельзя использовать? Я сам не пробовал просто

это проще делать из приложения

А чем тогда это будет отличаться от уровня приложения? Может побыстрее будет, но работать в приложении на родном языке со всеми инструментами отладки гораздо проще и удобнее.

И держать доменную логику в одном месте

Всем привет. Какие есть международные хорошие конфы по постгресу?

https://wiki.postgresql.org/wiki/Events

Ключевое было "хорошие" :)

Или в сообществе pg плохих ивентов не бывает?)

Вот взять например PgDay в Москве. Сколько там будет докладов на английском? Мне бюджет не дадут, если будет много докладов на русском с переводом. На сайте не написано об этом ни слова, программы нет.

pgday - в Питере. В Москве - pgconf2017

Ой, я щас смотрел pgconf в Москве.

В смысле сообщение выше мое было как раз про Pgconf

pgconf.us, pgcon в оттаве, pgconf.eu наверное самые представительные

а когда будет опубликован список докладов для pgconf ?

(московский который)

на московскую конференцию еще не завершен прием докладов

"25 января будет опубликована предварительная программа конференции."

Хочу вести базу хешей картинок (конкретно pHash) для similarity search в нормальном движке - может есть какой экстеншон типа mvp tree, чтоб индексировал многомерные данные?

для постгреса конечно*

Об этом речь? https://github.com/jirutka/smlar

Об этом речь? https://github.com/jirutka/smlar

тут просто набор ф-й которые можно использовать в кастомном индексе? Не вижу как из этого можно mvp tree построить

Попробуйте посмотреть в сторону KNN для SP-GIST

тут просто набор ф-й которые можно использовать в кастомном индексе? Не вижу как из этого можно mvp tree построить

там есть knn

вот тут дока подробнее написана: https://github.com/postgrespro/imgsmlr

для многомерных данных можно посмотреть cube и intarray в contrib

первое будет работать с knn для небольших размерностей (типо до десятка)

во втором можно больше измерений, но сильно чувствительно к кол-ву уникальных значений в каждой координате. Если будет много — индекс не построится за разумное время

Еще много данных можно привести к малой размерности или или малой уникальности координат сделав кластеризацию или PCA

такие дела)

Стас, спасибо за краткий обзор)

Попробуйте посмотреть в сторону KNN для SP-GIST

Неа, не пойдет для моей задачи. нужно искать N похожих среди нескольких миллиардов вот таких хешей: ba19c8ab5fa05a59

но спасибо за обзор, почитаю немного про imgsmlr

Неа, не пойдет для моей задачи. нужно искать N похожих среди нескольких миллиардов вот таких хешей: ba19c8ab5fa05a59

а как дистанция определена?

а как дистанция определена?

hamming distance

16 измерений, 16 уникальных значений в каждом. Intarray потянет

сложно сказать про миллиарды, не пробовал

700М в r-дереве с cube хорошо работало, но индекс был уже сильно жирный

вот тоже боюсь что индекс оч расплывется

интересно было бы посмотреть на реализацию чистой mvp бд с шардингом

если есть готовые данные я бы попробовал intarray knn на них