Ну ладно, может просто привести ряд примеров? А то так глядишь и я перейду в стан сторонников хранимок.

у нас есть логика выдачи контента с проверкой прав, так 1 запрос к хранимке, если нет, то 9 запросов к БД, при условии что в пиках 12К это позволяет достаточно комфортно работать

А вообще это все попахивает деструктурированием ПО - "зачем нам все эти иерархии классов, модели MVC, уровни доступа, разделения на бизнес логику и представление, когда можно просто быть поближе к базе и фигачить лапшекодом напрямую"

про функциональное программирование не слышали ? :)

зачем хранимая процедура там? накидываем запросы с WITH и прочим

@dbalakov я же написал либо CTE либо хранимка, какие проблемы ?

сорри - пропустил, у нас тут деплой идет еще)

зачем хранимая процедура там? накидываем запросы с WITH и прочим

как показала практика - их можно тестировать )

ага

проще чем сте

тестировать можно все - вопрос крови)

да и потом среднестатисический phpшник, не очен рад портянкам в 100+ строк на не понятном ему CTE

зависит от архитектры и того как вычленили дао слой

а вызов хранимки если он описан и тд итп то куда доступнее.

про функциональное программирование не слышали ? :)

А в функциональном программировании тоже все сложно, и куча паттернов и т.д. ;)

и SOLID никто не отменял)

@chebotarevp дак яж не спорю =)

всем чмоки, я домой. Если кому интересно https://github.com/postgres-ci/core/tree/master/tests , через пару недель ГУИ допилю, контейнеры на hub выложу и инструкцию по запуску )

“а вызов хранимки если он описан и тд итп то куда доступнее.” да - но внесение изменений сложней. Миграция и прочее.

поюзаем

@dbalakov обычно если до такого дошло то у компании есть DBD или DBA хотя бы а то и с десяток таких людей ;)

@dezconnect не всегда) не работали вы в кровавом месеве стартапов, все бы про крупный бизнес, да b2g)

да почему... были стартапы, и в них вполне неплохоя уживался как дба или дбд )

про функциональное программирование не слышали ? :)

а это вообще не про лапшу. Вы вступаете на очень скользкую дорогу :)

@dezconnect да шучу я) конечно кто-то отвечающий за БД нужен - лучше выделенный человек

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

лапша появляется не из-за инструмента, а из-за человека…

Васильев А.Ю. Работа с Postgresql настройка, масштабирование - кто нибудь читал?

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

Васильев А.Ю. Работа с Postgresql настройка, масштабирование - кто нибудь читал?

Это Леопард

тут его периодически критикуют

дак а разве кто-то кого то ругал ?

да, постоянно. Смотрите выше. Но аргументированной критики я не увидел

только на уровне "это плохо и опасно". Почему плохо и опасно мне так и не рассказали

тут его периодически критикуют

Стоит его читать?

Стоит его читать?

я ненастоящий DBA (я devops и немножечко программист). Я прочитал, мне помогло

только на уровне "это плохо и опасно". Почему плохо и опасно мне так и не рассказали

я в нескольких докладах видел как рассказывающие говорили типа так не надо делать это опасно итд и не рассказывали как надо?

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

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

а в чем проблемы с миграциями ?

“а вызов хранимки если он описан и тд итп то куда доступнее.” да - но внесение изменений сложней. Миграция и прочее.

Да камон - вы точно из не кушали. Проблем с миграцией хранимок не так много, как минимум в pg(в Ora это конечно боль) А вот проблем с миграцией данных на порядок больше.

Да камон - вы точно из не кушали. Проблем с миграцией хранимок не так много, как минимум в pg(в Ora это конечно боль) А вот проблем с миграцией данных на порядок больше.

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

Да камон - вы точно из не кушали. Проблем с миграцией хранимок не так много, как минимум в pg(в Ora это конечно боль) А вот проблем с миграцией данных на порядок больше.

Oracle, все на пакетах, EBR, боли нет, чмднт?)

Ну, миграции разные бывают, и кейсы разные бывают, но тоже не понимаю проблем с миграцией данных

Oracle, все на пакетах, EBR, боли нет, чмднт?)

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

В Ora "прекрасный" library cache - фигушки на живую базу что выкатишь. EBR не продавайте.

В Ora "прекрасный" library cache - фигушки на живую базу что выкатишь. EBR не продавайте.

Так он и без миграций проблем доставляет прилично

Не продаю, это просто один из подходов.

Но позволяет не останавливать базу вообще.

Ну я как раз пару лет назад его трогал - видимо как-то не ок хранимки были. Его клинило на пакетных типах. Типа head в ora$base, а что-то переопределенное в дочернем. Они в итоге патч сделали, но пробывать уже желания не было

Ну я как раз пару лет назад его трогал - видимо как-то не ок хранимки были. Его клинило на пакетных типах. Типа head в ora$base, а что-то переопределенное в дочернем. Они в итоге патч сделали, но пробывать уже желания не было

С function pipelined проблема в 11g, ее так и не не починили, остальное работает. Или починили, но у нас уже поддержка закончилась :^) короче, не используем.

Ага ну да и когда типы уровня пакета из неё возвращаешь.

Этого не застал. Но рассказывали, кажется.

Ну а мы на pg свинтили - там ddl транзакционный и без общего Кеша - думать не нужно

Ну а мы на pg свинтили - там ddl транзакционный и без общего Кеша - думать не нужно

Наверняка не зря, и бюджет разгрузили после неизбежных трат на перекат всего. Но иногда политика мешает таким шагам даже сильнее финансов :)

Oracle, все на пакетах, EBR, боли нет, чмднт?)

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

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

Ну да там менеджеры видимо разное парой курят. Ну да и хорошего там очистного UNDO, rman...

про NULL==0=='' еще не вспоминали?

Null ничему не равен :^)

Да и 0 is not null вообще-то.

Но вот со строками не так повезло

Коллеги,ищем сильных спикеров по Postgres, а то совсем провал на заявках на DC'16 http://devconf.ru/ru/offers/storage

Если есть возможность сделайте pin сообщению.

Коллеги,ищем сильных спикеров по Postgres, а то совсем провал на заявках на DC'16 http://devconf.ru/ru/offers/storage

а вы старые доклады планируете выкладывать?

Коллеги, направьте на путь истинный: есть табличка, в ней поле owner составного типа (id, type, name), выборки вида (owner).id=... and (owner).type=... Обычныйые индексы по этим полям он не видит почему-то, как индекс построить чтобы seq scan избежать?

функцинальный индекс построить например

Какая функция в этом случае у нас будет? Тут вроде как обычные операторы равенства

https://habrahabr.ru/post/282932/

Статейку читал, а вот как ее к моим барашкам применить не понятно

ну что-то вроде create index on t ((owner.id));

предполагаю =)

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

Кстати если в таблице мало записей может он забить на индекс и сделать seq scan?

конечно

Может забить:)

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

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

+ analyze <table>

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

+ analyze <table>

По дефолту вроде после 2к вставок само запустится?

Ну вроде как составной эффективней: типа он кусок индекса сканит уже отфильтрованный по первому критерию или я ошибаюсь?

По дефолту вроде после 2к вставок само запустится?

это смотря что в кофигах, нет?

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

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

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

The fillfactor for an index is a percentage that determines how full the index method will try to pack index pages. For B-trees, leaf pages are filled to this percentage during initial index build, and also when extending the index at the right (largest key values). If pages subsequently become completely full, they will be split, leading to gradual degradation in the index's efficiency. B-trees use a default fillfactor of 90, but any value from 10 to 100 can be selected. If the table is static then fillfactor 100 is best to minimize the index's physical size, but for heavily updated tables a smaller fillfactor is better to minimize the need for page splits. The other index methods use fillfactor in different but roughly analogous ways; the default fillfactor varies between methods.

это смотря что в кофигах, нет?

По дефолту в большинстве репозиториев с которыми я сталкивался, да :)

Благодарюза ртфм кратко и доходчиво

Вот я сейчас не понял, сарказм или нет:) Для таблиц, кстати, тоже еcть fillfactor, иногда помогает его покрутить.

По дефолту в большинстве репозиториев с которыми я сталкивался, да :)

эх, привычка делать "контрольный" vacuum analyze..)

Ок, спасибо большое

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

только через диалоги он с fillfactor кривовато работает. например, не дает выставить дефолтное значение

Вот я сейчас не понял, сарказм или нет:) Для таблиц, кстати, тоже еcть fillfactor, иногда помогает его покрутить.

а когда помогает ? вдруг кто сейчас начнет его крутить, а планировщик так и будет сек сканы выдавать ;)

а когда помогает ? вдруг кто сейчас начнет его крутить, а планировщик так и будет сек сканы выдавать ;)

Не, в других случаях помогает. Когда, например, апдейтов много по таблице, маленькие значения помогают ускорить апдейты. Особенно когда меняются только поля, по которым нет индексов.

ок)

Предлагаю запилить в этот чат @comstatbot

Позволяет вести и следить за статистикой

да тут вроде как не настолько активно пишут, чтобы следить

или есть дополнительные профиты?

или есть дополнительные профиты?

Тут можно глянуть. https://comstatbot.xyz/