"Postgres тоже использует размер выравнивания в восемь байтов. " Нет, см. pg_types, колонка typalign Все, разумеется, описано в документации. Дальше читать не стал и другим не советую.
Да все я правильно понимаю. Консистентность или есть, или нет. У вас ее нет. Про нужды студентов будете на суде рассказывать, хорошо если как свидетель, когда сотрудник сопрет средства клиента и объявит это "имманентной неконсистетностью". Отдельно замечу, что судья в этих косистентностях вообще не разбирается.
Прежде чем будет выбран какой-то план, необходимо построить все возможные планы (ну там сложнее, конечно, в общем случае) и оценить их стоимость. Так что это влияет на точность оценки количества строк при соединении; а это уже влияет на точность выбора оптимального плана оптимизатором; так что да, влияет. Разумеется, это не гарантия того, что все будет отлично или даже что оптимизатор выберет действительно оптимальный план, но тем не менее.
Честно говоря, мне показалось, что решение переусложнено. Автор там и сам пишет, что можно было бы обойтись select for update или уровнем serializable; да, при высокой нагрузке это действительно может вызвать проблемы, но, как мне кажется, бизнес от подобных проблем (продажи идут с такой скоростью, что СУБД не успевает их размещать) будет только счастлив. Ну и, опять же, в случае постгреса это обходится процедурой/триггером и advisory блокировкой.
В данном случае соотношение BTC/ETH, чтобы значения в паре были более-менее в рамках здравого смысла. Рост человека не больше 2.5м, одинокий ребенок не может быть ответственным квартиросъемщиком и т.п.
То есть на Югославию-Ирак-Ливию-Сирию вы внимания как-то не обратили? Вот серьезно?
Потрясающе.
Ну как дураки. Можно сказать, я встретил розового пони живьем.
Я стесняюсь спросить, вы новости по телевизору когда-нибудь смотрели?
Ну да, зима всегда наступает внезапно. Вы серьезно это пишете?
Обалденно.
"Postgres тоже использует размер выравнивания в восемь байтов. "
Нет, см. pg_types, колонка typalign
Все, разумеется, описано в документации.
Дальше читать не стал и другим не советую.
seller_id выглдядит как первичный ключ. к чему еще сортировать набор из одного элемента по имени - непонятно совершенно
к сожалению, заменили очень удачную кнопку "режим чтения" на эту вот белиберду :-(
exception when others then null;Какая прелесть!
Да что далеко ходить, есть цикл статей моего коллеги, там и это рассматривается, причем прямо здесь
https://habr.com/ru/company/postgrespro/blog/579024/
Отдельно очень рекомендую его книжку, https://postgrespro.ru/education/books/internals
Да все я правильно понимаю.
Консистентность или есть, или нет. У вас ее нет.
Про нужды студентов будете на суде рассказывать, хорошо если как свидетель, когда сотрудник сопрет средства клиента и объявит это "имманентной неконсистетностью".
Отдельно замечу, что судья в этих косистентностях вообще не разбирается.
Не "ускорить join". Кажется, Вы не понимаете, о чем речь.
Я правильно понимаю, что вы утвеждаете "если вам не важна целостность данных, то констрейнтами можно не пользоваться"?
Прежде чем будет выбран какой-то план, необходимо построить все возможные планы (ну там сложнее, конечно, в общем случае) и оценить их стоимость.
Так что это влияет на точность оценки количества строк при соединении; а это уже влияет на точность выбора оптимального плана оптимизатором; так что да, влияет.
Разумеется, это не гарантия того, что все будет отлично или даже что оптимизатор выберет действительно оптимальный план, но тем не менее.
Причем тут индекс вообще? Это нужно для оценки кардинальности соединения, до индексов еще далеко.
Ну подумайте - при соединении можно утверждать, что для вот этой строки точно найдется другая и причем только одна.
Ну вот на нем и свалится :-)
Честно говоря, мне показалось, что решение переусложнено. Автор там и сам пишет, что можно было бы обойтись select for update или уровнем serializable; да, при высокой нагрузке это действительно может вызвать проблемы, но, как мне кажется, бизнес от подобных проблем (продажи идут с такой скоростью, что СУБД не успевает их размещать) будет только счастлив. Ну и, опять же, в случае постгреса это обходится процедурой/триггером и advisory блокировкой.
В данном случае соотношение BTC/ETH, чтобы значения в паре были более-менее в рамках здравого смысла. Рост человека не больше 2.5м, одинокий ребенок не может быть ответственным квартиросъемщиком и т.п.
С ОРМ можно жить, другое дело что он дубовый, как хороший гроб.
Предлагаемый подход, впрочем, еще хуже.
Живите, чего уж.