а так же отсутствует гарантия консистентности данных и целосности

а так ничо страшного. да

а так ничо страшного. да

ну есть же люди, которые монгу, и ничего, норм. Все зависит от задачи и требований

еще и очень большая избыточность. одно и тоже в раных записях можно хранить отдельно и связывать ключами.

еще и очень большая избыточность. одно и тоже в раных записях можно хранить отдельно и связывать ключами.

денормализация данных для ускорения чтения вполне допустима, главное, как и в любом деле, не увлекаться сильно. Про какие объемы данных идет речь?

да и вообще не думают о тому «нучно ли это в базе?» на всякий случай пихают все, «а вдруг пригодится». Короче не база а помойка получилась.

а как в постгре с масштабируемостью? у монги просто все хорошо

>Когда получилось, что нужно делать онлайново запрос с 20 джойнами с огромным rps 20 джойнов это по-моему перебор для запроса с большим rps и может говорить о 1) не совем подходящей аритектуре сервиса 2) о плохо спроектированной схеме данных

> 20 джойнов это по-моему перебор для запроса с большим rps Это, разумеется, перебор > 1) не совем подходящей аритектуре сервиса Это наследие мохнатых лет. Когда в мускуле возникали проблемы из-за "плотных" таблиц – динозавры писавшие проект их распилили на много. Типа: юзеры - настройки юзеров - опции юзеров. Контент - настройки контента и т.д. И распилили размашисто. > 2) о плохо спроектированной схеме данных Это вытекает из первого В общем-то мы это решаем предагрегацией таблиц пока что и затем реплицируем Slony на базу, которая используется под большим rps.

денормализация данных для ускорения чтения вполне допустима, главное, как и в любом деле, не увлекаться сильно. Про какие объемы данных идет речь?

Да да, а потом получается протестили на 10-20Гб, а на 300-600Гб вдруг все стало работать не миллисекунды, а минуты. И еще и легаси кода под это написано за 2 года, и скоро MVP и поэтому менять особо уже что либо поздно )

а как в постгре с масштабируемостью? у монги просто все хорошо

у монги все хорошо?

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

у монги все хорошо?

а что плохо?

хаять

ладно

исправил

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

а причем тут монга ? тут речь шла про использования JSON в постгресе.

сейчас не знаю, как обстоят дела, но вряд ли лучше

а причем тут монга ? тут речь шла про использования JSON в постгресе.

речь не про монгу? ранее скидывали ссыль, я подумал, что после этого начался срач. тогда сори. продолжайте)

Сколько можно мусолить этот холивар, что лучше монга или постгрес или что-то ещё? Для каждого случая своя БД. По ресурсам железа, человеческим ресурсам (написание кода и обслуживание и др.), количества денег и т.п.

вот сейчас точно прорвет

вот кто где берет инфу по моделям данных ? по всяким Anchor / Data Vault и прочему ?

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

речь не про монгу? ранее скидывали ссыль, я подумал, что после этого начался срач. тогда сори. продолжайте)

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

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

Ну классический отстрел ноги.

а как в постгре с масштабируемостью? у монги просто все хорошо

У монги? Масштабируемость?!

У монги? Масштабируемость?!

да, а что смущает? на чтение она хорошо масштабируется

на запись - боль-боль

точнее, боль**боль

да, а что смущает? на чтение она хорошо масштабируется

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

Вообще, эхотаг - это СУБД, а монга - это какая-то маловменяемая обертка для БД.

Фидошники в треде. :)

Не-не-не! Я - околофидошник! :)

Ну и кто тебе теперь поверит? ;)

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

Сейчас [*] прилетит. :))

даешь ююки на бекбон!

Ладно, надо какой-нибудь антиоффтопик залудить. А именно, благородные доны, а что есть для работы с иерархическими данными помимо рекурсивных запросов с WITH и ltree? Ну не считая более старых наработок? Или всё продолжает оставаться грустным и печальным?

уф, я начал было уже предполагать, что чат скатывается в @dba_ru

Ладно, надо какой-нибудь антиоффтопик залудить. А именно, благородные доны, а что есть для работы с иерархическими данными помимо рекурсивных запросов с WITH и ltree? Ну не считая более старых наработок? Или всё продолжает оставаться грустным и печальным?

https://postgrespro.ru/docs/postgresql/9.6/tablefunc.html

При ресторе БД есть ли способ указать для pg_restore не обновлять матвьюхи?

Vadim спасибо, посмотрю.

не за что. Смотрите в сторону функции connectby

а что унутри connectby() ? рекурсия ? или однопроходный алгоритм ?

Всем привет, кто то юзал mysql_fdw? Он при хитрых запросах с агрегацией где агрегирует? Там или тут?

тут

Спс

Друзья, здесь приветствуются вопросы «помогите разобраться с запросом, я сам не местный»?

Друзья, здесь приветствуются вопросы «помогите разобраться с запросом, я сам не местный»?

Вопрос задай сначала.

Так уже задал. :)

SELECT * FROM a LEFT JOIN LATERAL ( SELECT bla-bla ) l ON true Это что за конструкция c LATERAL?

SELECT * FROM a LEFT JOIN LATERAL ( SELECT bla-bla ) l ON true Это что за конструкция c LATERAL?

Документацию смотрел? У гугла спрашивал?

Нет, конечно, потому и спрашиваю здесь

если бы смотрел, уже б читал

Позволяет обращаться к таблицам внешнего запроса из подзапроса.

Появилось в 9.3 - крутая штука.

то есть это как бы и не джойн, а просто ссылка на подзапрос?

а можно как-то в array_agg передать функцию, которая вовзращает set ? конкретно хочу json_object_keys

а можно как-то в array_agg передать функцию, которая вовзращает set ? конкретно хочу json_object_keys

что угодно можно городить подзапросами

ну так я и сделал.. но хочется без :)

Привем всем, где в explain у insert from select указанно сколько времени он потратил на вставку данных, а сколько на их выборку из таблиц?

Строка NestedLoopAntiJoin - время, затраченное на операции плана, реализующие чтение/обработку

Хорошо, но, сказанно что AntiJoin выдал 33т строк, но у плана insert actual_time время начала вставки и окончания равны, т.е вставил он 33т строк за 0мс?

Почему вообще anti_join выдал 33т строк, а у insert 0 строк в explain’е

Почему вообще anti_join выдал 33т строк, а у insert 0 строк в explain’е

Потому что это просто explain без analyze. Он представил как будет делать, но не сделал.

Хорошо, но, сказанно что AntiJoin выдал 33т строк, но у плана insert actual_time время начала вставки и окончания равны, т.е вставил он 33т строк за 0мс?

Это не время начала и окончания, это время на первую строку и на все строки так как строк ноль то они равны

Потому что это просто explain без analyze. Он представил как будет делать, но не сделал.

actual_time в explain без analyze ты как себе предсатавляешь

Потому что это просто explain без analyze. Он представил как будет делать, но не сделал.

Нет так анплайз

actual_time в explain без analyze ты как себе предсатавляешь

А точно. Не заметил.

Это не время начала и окончания, это время на первую строку и на все строки так как строк ноль то они равны

это да, но я не понимаю почему anti join выдал 30к строк, а вставил 0

может просто не теребонькать и сделать insert on conflict do nothing?

может сначала просто на селект посмотреть без инсерта?

а можно обернуть в begin end сделать реальный insert с аналазом и открать в конце и постреть на реальный план

так в доках рекомендую(по крайней мере для explain analyze update table )

Вы что не видите что это explain analyze из логов postgres? Это extentions для постгреса auto_explain.

\

ф

подсазжите пожалуйста как поменять "тип символа" и "Сопоставление"

подсазжите пожалуйста как поменять "тип символа" и "Сопоставление"

Только создав новую базу

Не подскажете как проще всего сделать INSERT в таблицу с типом данных jsonb 20 000 строк? Собственно содержимое этих строк имеется в файле.

\copy table from aaa.txt

Как можно сделать SELECT по jsonb вида {700:[{"A":"Happold","B":"F. C.","G":"Frederick Crossfield","F":"1893- "}]} если нужно получить значение ключей A: B: и тд из массива?

https://www.postgresql.org/docs/9.5/static/functions-json.html

Привет, народ) Подскажите, как замутить двустороннюю связанность? т.е. мне надо сделать так, чтобы при удалении записи их одной таблицы удалялась связанная с ней запись в другой. И наоборот)

Это называется внешний ключ. При создании внешнего ключа надо указать ON DELETE CASCADE

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

Если не сработает, тогда можно сделать 2 одинаковых колонки id1 и id2 в таблицах, и друг ну друга внешние ключи указать.