Имхо главная проблема натуральных ключей — в том, что "натуральность" меняется со временем, и делать соответствующие доработки в ПО может оказаться слишком дорого. Ну, грубо говоря, ИНН сейчас есть у всех граждан РФ и не меняется в течение жизни, так что если вы делаете что-то типа госуслуг, то почему бы не сделать его первичным ключом? А через год принимают закон, по которому ИНН становится можно менять по заявлению, и... ой.

https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_money

всего голосов 1: ↑3/2ħ и ↓-1/2ħ

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

Хорошо что не 0.3000004.

За первый пункт +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

в небольших конторах один человек может совмещать обязанности ПМ-а, аналитика, инженера-внедренца... он даже ещё и тимлидом может оказаться :)

К сожалению, такой вопрос может привести к ещё более печальным результатам:

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

• либо заказчик уйдёт выяснять все эти особенности внутри себя самостоятельно, и в лучшем случае вернётся через несколько месяцев — или вообще не вернётся, и проект заглохнет совсем.

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

1) по умолчанию не материализуются, 2) если материализуются, то по умолчанию не на диск (на диск только если памяти не хватит).

Так было только до 11й версии (т.е. очень давно). Начиная с 12й, по умолчанию не материализует, но при необходимости даёт возможность явно материализовать при помощи ключевого слова.

Правда, статистики по результату материализации CTE всё равно не бывает.

Про временные таблицы фактическая ошибка — написано что они почему-то всегда работают с диском, что ерунда: это такие же таблицы, как и все остальные. У них есть недостатки, но совсем другие.

если соло в смысле фрилансер, то общаться придётся вообще с заказчиком, а не с такими же программистами-гиками.

если соло это в смысле тихо сам для себя... но так деньги не заводятся :)

ну а что, мне известен случай переквалификации из разработчика в баристу.

Непонятно совпадение или что, но сегодня ещё и scheduled maintenance у cloudflare (который стоит перед многими популярными сервисами).

Ну известно же, что это неправильная картинка. Правильная вот:

https://imgur.com/Hs9auHg.jpg

А если серьёзно, то эти круги надо рисовать не на множествах A и B, а на декартовом произведении AxB, от чего наглядность несколько улетучивается.