За первый пункт +100500. Классический приём: письмо 10 адресатам с вопросом вида "Коллеги, что будем делать" или "коллеги, когда будет YYY". Естественно, все 10 адресатов молчат, потому что каждый думает, что спрашивают не его. Есть подозрение, что некоторые товарищи такое письмо применяют для ИБД: вроде как ПМ своё дело сделал, команду потеребил, а команда ни гугу.
это именно лимит, а не способ разделить ресурсы по разным пользователям. На практике, юзер в БД — это обычно не юзер в смысле человек, а приложение. Поэтому, если у вас например есть какое-нибудь мониторинговое приложение, и есть основания опасаться, что оно внезапно (из-за бага или уязвимости) откроет 100 подключений, можно ему зарезать connection limit. А основному бизнес-приложению не ограничивать, т.к. это как раз для него предназначенная БД.
ну как-то не понятно зачем сомневаться, если легко проверить.
portnov=# show max_connections;
max_connections
-----------------
100
(1 row)
portnov=# create user usr1 with connection limit 30;
CREATE ROLE
portnov=# create user usr2 with connection limit 30;
CREATE ROLE
portnov=# create user usr3 with connection limit 30;
CREATE ROLE
portnov=# create user usr4 with connection limit 30;
CREATE ROLE
portnov=# create user usr5 with connection limit 30;
CREATE ROLE
portnov=# create user usr6 with connection limit 30;
CREATE ROLE
portnov=# create user usr7 with connection limit 30;
CREATE ROLE
portnov=# create user usr8 with connection limit 30;
CREATE ROLE
portnov=# create user usr9 with connection limit 30;
CREATE ROLE
portnov=# create user usr10 with connection limit 30;
CREATE ROLE
portnov=# \du usr*
List of roles
Role name | Attributes | Member of
-----------+----------------+-----------
usr1 | 30 connections | {}
usr10 | 30 connections | {}
usr2 | 30 connections | {}
usr3 | 30 connections | {}
usr4 | 30 connections | {}
usr5 | 30 connections | {}
usr6 | 30 connections | {}
usr7 | 30 connections | {}
usr8 | 30 connections | {}
usr9 | 30 connections | {}
вот подключиться всем этим пользователям по 30 раз каждому одновременно — PG не даст, max_connections не позволит.
так можно убедиться, что PG действительно "увидел" huge pages и стал ими пользоваться: если почему-то не получится, он упадёт на старте, а не будет молча работать в "медленном" режиме, как при try.
вы ссылаетесь на документацию конкретного облачного сервиса. В PG такой параметр у юзера есть, но он не обязательный, по дефолту не задан, и даже если задан — он не отбирает лимиты у других юзеров. Ну, просто потому, что у них-то этого лимита нету. https://postgrespro.ru/docs/postgresql/16/sql-createrole
К сожалению, такой вопрос может привести к ещё более печальным результатам:
либо ответ лежит в таких дебрях особенностей бизнеса заказчика, которые вы не хотите знать, а если захотите, то на изучение потратите месяцы, а в конце концов выясните, что это (через длинную цепочку причин и следствий) из-за того, что главбух недолюбливает финдиректора, но вы-то ни на того, ни на другого повлиять не сможете, так что требование останется как есть.
либо заказчик уйдёт выяснять все эти особенности внутри себя самостоятельно, и в лучшем случае вернётся через несколько месяцев — или вообще не вернётся, и проект заглохнет совсем.
постгрес из коробки, как известно, настроен так, чтобы запускаться на кофемолках. Поэтому, не стоит делать далеко идущие выводы из значений настроек по умолчанию, если вы запускаетесь на любом современном железе.
Так было только до 11й версии (т.е. очень давно). Начиная с 12й, по умолчанию не материализует, но при необходимости даёт возможность явно материализовать при помощи ключевого слова.
Правда, статистики по результату материализации CTE всё равно не бывает.
Про временные таблицы фактическая ошибка — написано что они почему-то всегда работают с диском, что ерунда: это такие же таблицы, как и все остальные. У них есть недостатки, но совсем другие.
Суть в том, что массив (table of something) — это данные, хранящиеся в RAM сервера БД. Если в отведённый размер RAM не влезет, будет либо своппинг, либо использование временного табличного пространства, либо ошибка out of memory. В любом случае ничего хорошего. Делать массив размера, сопоставимого с количеством RAM, заведомо плохая идея.
Т.е. если у вас реальный код был написан действительно именно так, как в статье (затаскиваем весь результат выборки в массив и потом с ним работаем), то вполне возможно, что тормоза вообще даже не из-за джойнов и не из-за неэффективного запроса, а просто из-за того, что сервер БД ушёл своппиться.
Курсоры ладно, иногда нужны. Но в варианте где большой запрос, я так и не понял, зачем так делать:
открываем курсор по большому количеству данных
зачитываем все данные в RAM сервера БД. Скажите спасибо ещё что out-of-memory не словили, с большой вероятностью сервер БД полез во временное табличное пространство или своп.
а потом ещё и ничего не делаем с зачитанным массивом, просто return. Но тут я предполагаю что опечатка, имели ввиду return l_events_tab.
всего голосов 1: ↑3/2ħ и ↓-1/2ħ
три с половиной землекопа.
Хорошо что не 0.3000004.
За первый пункт +100500. Классический приём: письмо 10 адресатам с вопросом вида "Коллеги, что будем делать" или "коллеги, когда будет YYY". Естественно, все 10 адресатов молчат, потому что каждый думает, что спрашивают не его. Есть подозрение, что некоторые товарищи такое письмо применяют для ИБД: вроде как ПМ своё дело сделал, команду потеребил, а команда ни гугу.
и что характерно - такой ответ с большой вероятностью будет передан выше по инстанциям дословно именно в таком виде. Или даже напрямую клиенту.
это именно лимит, а не способ разделить ресурсы по разным пользователям. На практике, юзер в БД — это обычно не юзер в смысле человек, а приложение. Поэтому, если у вас например есть какое-нибудь мониторинговое приложение, и есть основания опасаться, что оно внезапно (из-за бага или уязвимости) откроет 100 подключений, можно ему зарезать connection limit. А основному бизнес-приложению не ограничивать, т.к. это как раз для него предназначенная БД.
ну как-то не понятно зачем сомневаться, если легко проверить.
вот подключиться всем этим пользователям по 30 раз каждому одновременно — PG не даст, max_connections не позволит.
так можно убедиться, что PG действительно "увидел" huge pages и стал ими пользоваться: если почему-то не получится, он упадёт на старте, а не будет молча работать в "медленном" режиме, как при try.
вы ссылаетесь на документацию конкретного облачного сервиса. В PG такой параметр у юзера есть, но он не обязательный, по дефолту не задан, и даже если задан — он не отбирает лимиты у других юзеров. Ну, просто потому, что у них-то этого лимита нету.
https://postgrespro.ru/docs/postgresql/16/sql-createrole
в небольших конторах один человек может совмещать обязанности ПМ-а, аналитика, инженера-внедренца... он даже ещё и тимлидом может оказаться :)
К сожалению, такой вопрос может привести к ещё более печальным результатам:
либо ответ лежит в таких дебрях особенностей бизнеса заказчика, которые вы не хотите знать, а если захотите, то на изучение потратите месяцы, а в конце концов выясните, что это (через длинную цепочку причин и следствий) из-за того, что главбух недолюбливает финдиректора, но вы-то ни на того, ни на другого повлиять не сможете, так что требование останется как есть.
либо заказчик уйдёт выяснять все эти особенности внутри себя самостоятельно, и в лучшем случае вернётся через несколько месяцев — или вообще не вернётся, и проект заглохнет совсем.
постгрес из коробки, как известно, настроен так, чтобы запускаться на кофемолках. Поэтому, не стоит делать далеко идущие выводы из значений настроек по умолчанию, если вы запускаетесь на любом современном железе.
1) по умолчанию не материализуются, 2) если материализуются, то по умолчанию не на диск (на диск только если памяти не хватит).
Так было только до 11й версии (т.е. очень давно). Начиная с 12й, по умолчанию не материализует, но при необходимости даёт возможность явно материализовать при помощи ключевого слова.
Правда, статистики по результату материализации CTE всё равно не бывает.
Про временные таблицы фактическая ошибка — написано что они почему-то всегда работают с диском, что ерунда: это такие же таблицы, как и все остальные. У них есть недостатки, но совсем другие.
если соло в смысле фрилансер, то общаться придётся вообще с заказчиком, а не с такими же программистами-гиками.
если соло это в смысле тихо сам для себя... но так деньги не заводятся :)
ну а что, мне известен случай переквалификации из разработчика в баристу.
Непонятно совпадение или что, но сегодня ещё и scheduled maintenance у cloudflare (который стоит перед многими популярными сервисами).
Ну известно же, что это неправильная картинка. Правильная вот:
https://imgur.com/Hs9auHg.jpg
А если серьёзно, то эти круги надо рисовать не на множествах A и B, а на декартовом произведении AxB, от чего наглядность несколько улетучивается.
Суть в том, что массив (table of something) — это данные, хранящиеся в RAM сервера БД. Если в отведённый размер RAM не влезет, будет либо своппинг, либо использование временного табличного пространства, либо ошибка out of memory. В любом случае ничего хорошего. Делать массив размера, сопоставимого с количеством RAM, заведомо плохая идея.
Т.е. если у вас реальный код был написан действительно именно так, как в статье (затаскиваем весь результат выборки в массив и потом с ним работаем), то вполне возможно, что тормоза вообще даже не из-за джойнов и не из-за неэффективного запроса, а просто из-за того, что сервер БД ушёл своппиться.
Курсоры ладно, иногда нужны. Но в варианте где большой запрос, я так и не понял, зачем так делать:
открываем курсор по большому количеству данных
зачитываем все данные в RAM сервера БД. Скажите спасибо ещё что out-of-memory не словили, с большой вероятностью сервер БД полез во временное табличное пространство или своп.
а потом ещё и ничего не делаем с зачитанным массивом, просто return. Но тут я предполагаю что опечатка, имели ввиду return l_events_tab.