Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Релиз СУБД PostgreSQL 17"	+/–
Сообщение от opennews (??), 26-Сен-24, 20:33
После года разработки опубликована новая стабильная ветка СУБД PostgreSQL 17.  Обновления для новой ветки будут выходить в течение пяти лет до ноября 2029 года. Поддержка  PostgreSQL 12.x, самой старой из поддерживаемых веток, будет прекращена 14 ноября... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61935
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Релиз СУБД PostgreSQL 17"	+1 +/–
Сообщение от Walker (??), 26-Сен-24, 20:33
> Добавлена новая утилита pg_createsubscriber для преобразования физической реплики в новую логическую реплику. Годнота! Тут от Postgres Professional стрим смотрел про это, классно https://www.youtube.com/watch?v=peLXtGorl8A
Ответить | Правка | Наверх | Cообщить модератору

	13. "Релиз СУБД PostgreSQL 17"	–7 +/–
	Сообщение от penetrator (?), 27-Сен-24, 03:05
	сначала создали проблему, потому филигранно ее решили? молодцы )))
	Ответить | Правка | Наверх | Cообщить модератору

	78. Скрыто модератором	–8 +/–
	Сообщение от Аноним (78), 27-Сен-24, 17:06
	Корректная ссылка на видео - https://rutube.ru/video/9e2f11226b6c05d70937232c0d17da29/
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. "Релиз СУБД PostgreSQL 17"	+4 +/–
Сообщение от нах. (?), 26-Сен-24, 20:47
> При выполнении операции VACUUM мляааааа... в 2009м году они его обещали ОТМЕНИТЬ! Окончательно и бесповоротно! Кстати, где тот хмырь что год назад обещал нам новый формат хранилища не требующий вакума, уже почти и вот-вот? Убили и съели?
Ответить | Правка | Наверх | Cообщить модератору

	7. "Релиз СУБД PostgreSQL 17"	+1 +/–
	Сообщение от Аноним (7), 26-Сен-24, 21:26
	не знаю, какой там хмырь что обещал, но постгрес без вакуума есть: https://github.com/orioledb/orioledb да, одним extension не обойтись - постгрес всё еще нужно патчить.
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Релиз СУБД PostgreSQL 17"	+1 +/–
	Сообщение от нах. (?), 27-Сен-24, 08:54
	скорее это его нет чем есть - Commits on Sep 26, 2024     feature: Lock S3 bucket on startup (#371) za-arthur committed Sep 26, 2024 Commits on Sep 18, 2024     Use yapf to format root folder python scripts     akorotkov  committed Sep 18, 2024     Update copyright akorotkov committed Sep 18, 2024 Commits on Jul 21, 2024 работа, как видим, кипитЪ! А статус по прежнему - "пригодно для экспериментов". Год уже прошел, или больше?
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (86), 27-Сен-24, 21:37
	Ну, как proof of concept есть. А то, что никто на это время не дал ему денег на "допилить" - тут одно из двух: либо он не смог никому, у кого есть деньги, объяснить пользу, либо это никому не надо.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Релиз СУБД PostgreSQL 17"	+2 +/–
	Сообщение от Прохожий (??), 27-Сен-24, 22:55
	Есть ещё один вариант, наиболее вероятный: денег нет и не будет. Сами едва живы.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от scriptkiddis (?), 29-Сен-24, 09:35
	С таким флагом из всех щелей он деняг и не получит.
	Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

	44. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от anguest (?), 27-Сен-24, 13:09
	Недавно тестировал на нагрузках. Еще сырое, после определенного кол-ва активных инсертов начинаются утечки памяти и все падает.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	11. "Релиз СУБД PostgreSQL 17"	+3 +/–
	Сообщение от Аноним (11), 26-Сен-24, 23:36
	Так ведь вакуум - это следствие того, что сама БД - версионка. И оперирует версиями строк, что как бы еще в самом начале рассказывают.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	16. "Релиз СУБД PostgreSQL 17"	–1 +/–
	Сообщение от Аноним (16), 27-Сен-24, 08:04
	Как бы в 21 веке оперировать версиями строи и потом запускать вакуум некошерно. Не неходите? Это же не 70-е годы того века. Почти 50 лет от тех времен прошло. ПС. Оакловый подход, в общем, тоже немного устарел, но более комфортен при промышленной эксплуатации
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (52), 27-Сен-24, 14:21
	> Как бы в 21 веке оперировать версиями строи и потом запускать вакуум некошерно. Не неходите? Это же не 70-е годы того века. Почти 50 лет от тех времен прошло. Какая разница сколько прошло и какой сейчас век. Байтам больше 50 лет, так что, ими некошерно пользоваться? Возвращаясь к вакууму - что, придумали что-то лучше? Только не говори что undo логи писать которые то же самое, только наоборот, при этом сложнее и медленнее.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Релиз СУБД PostgreSQL 17"	+2 +/–
	Сообщение от Прохожий (??), 27-Сен-24, 23:08
	> Возвращаясь к вакууму - что, придумали что-то лучше? Только не говори что undo логи писать которые то же самое, только наоборот, при этом сложнее и медленнее. Не то же самое, всё же. Там этим vacuum-ом не надо заниматься, всё автоматически делается. И это, вакуум быстрый, что ли? Да не смеши мои тапки. Кроме того, ты, очевидно, этого не знаешь. Но undo можно положить на другую дисковую подсистему. А с vacuum-ом ты приплыл, никак не масштабируется, потому что in-place.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Релиз СУБД PostgreSQL 17"	–1 +/–
	Сообщение от Аноним (16), 28-Сен-24, 11:13
	К сожалению подросло поколение людей, которые не только не знают и не хотят ничего знать, но и гордятся своим незнанием - примерно как в фильме "Идиократия". И ваше объяснение - это как метать бисер перед нечистоплотными животными, может быть. Хорошо если это будет не так, и они пойдут, найдут информацию, попробуют ее понять, и сделают для себя какие-то полезные выводы.
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Наме (?), 28-Сен-24, 13:57
	Специфика работы MVCC в Оракле сложна и запутана. Вникать в её тонкости практически нет никакого смысла, потому что процесс этот для настройки почти не доступен, да и от версии к версии меняется (хотя с 11-той версии, вроде как, не особо). Знают её единицы, и то по случайности. Вот я один из таких единиц. Выносить UNDO с другую точку монтирования штука полезная, но и в случае Слона проблема с вв имеет свои решения, но уже на уровне ОС или оборудования, а не на уровне СУБД. Слон вообще полуфабрикат, его не стоит сравнивать с готовыми коммерческими продуктами. На базе Слона можно сделать вполне годную СУБД под свои задачи, главное не пытаться подходить к этому со стереотипами, выработанными при работе с Майком или Ораклом.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Наме (?), 28-Сен-24, 13:50
	Вакуум быстрый, да. Не помню уже с какой версии стало сильно быстрее, по-моему, с 13 или 14-той. Главное под автовакуум места не жалеть.
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	106. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Наме (?), 28-Сен-24, 14:02
	Места в смысле оперативы.
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (61), 27-Сен-24, 15:13
	Вижу знатока. Чем же подход Оракла отличается от того, что используется в Postgres? Ну-ка, ну-ка. Открываю большую пачку с чипсами.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	88. "Релиз СУБД PostgreSQL 17"	+2 +/–
	Сообщение от Прохожий (??), 27-Сен-24, 22:58
	Там нет vacuum. Видимо, этим. А что же там есть? Там есть отдельное табличное пространство для целей сохранения предыдущих значений (до начала транзакции). Недостатки: для длинной транзакции rollback может длиться очень долго (столько же, сколько изменение данных во время транзакции). Достоинства - откаты данных происходят сравнительно редко, поэтому нет необходимости постоянно делать vacuum.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Наме (?), 28-Сен-24, 11:35
	Это как если житель, скажем, рязанской области, зайдя в магаз где-нибудь где-нибудь в Станбуле, не нашёл бы там товара с названием Хлеб и заявил, что турки хлеба не едят. Оракл тоже хранит хронологические данные. Да, в отдельном ТП, но данные туда надо перемещать, это дополнительные затраты, к тому же Оракл хранит там чаще всего не целые строки, а дифы и директивы отмены, что сильно экономит место, если изменение небольшое, а строка большая, но делает процесс построения актуального значения блока для запросившей транзакции делом довольно затратным. Затратным относительно Слона, у которого хронологические данные никак от "живых" не отличаются и доступны сразу там же. И точно так же надо в Оракле следить за размером UNDO. Ну и ты сам в чатгпт вычитал, что подход Оракла тормозит в случае отката. Прям, сильно тормозит. Вряд ли ты знаешь почему. А вот утверждение, что транзакции куда чаще завершаются фиксацией, чем откатом, это, мягко говоря, очень сильное допущение. В общем, mvcc это всегда необходимость хранить хронологические данные и всегда необходимость строить из этих данных блоки под конкретную транзакцию. Реализаций есть множество и какой-то волшебной превосходящей всех и вся до сих пор нет.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Релиз СУБД PostgreSQL 17"	+1 +/–
	Сообщение от Прохожий (??), 29-Сен-24, 11:01
	>Ну и ты сам в чатгпт вычитал, что подход Оракла тормозит в случае отката. Прям, сильно тормозит. Вряд ли ты знаешь почему. Столько глупых предположений в одном сообщении... Нет, я вычитал всё это из документации, а не чатжпт. Потому что приходилось иметь дело с обеими СУБД на практике в течение многих лет (особенно с Ораклом, с Постгре всего года два, да и то только в разработке). Тормозит потому, что данные из Undo копируются назад. Но ещё раз, Undo можно положить на другую дисковую систему, в отличие от. >А вот утверждение, что транзакции куда чаще завершаются фиксацией, чем откатом, это, мягко говоря, очень сильное допущение. Правда, что ли? Предлагаю подумать головой более тщательно, прежде чем писать подобное.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Наме (?), 29-Сен-24, 23:47
	Специфики работы UNDO в документации нет вообще, она там не нужна. Как нет и ничего про внутренние процессы сервера. Медийных материалов по этой теме, кроме одной единственной книжки Льюиса начала 10-х, тоже нет. Поэтому и чатгпт. Тормозит не потому, что что-то там "копируется назад" (и что это за "назад" такой???). Хотя, ещё раз, это не важно особо.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Релиз СУБД PostgreSQL 17"	+1 +/–
	Сообщение от mos87 (ok), 27-Сен-24, 08:05
	эта одна из первых вещей, которые рассказывают тем же (будущим) админам ПГ а потом ещё про "переполнение" какого-то счётчика.
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

	19. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от нах. (?), 27-Сен-24, 08:56
	погоди, они и это не смогли починить?! Про "переполнение" мне тоже рассказывали... давным-давно со словами "ну вот щас-щас щас решим и эту проблему".
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Релиз СУБД PostgreSQL 17"	+2 +/–
	Сообщение от mos87 (ok), 27-Сен-24, 09:04
	Мне рассказывал толковый тыЮтор, возможно поэтому про щастамвсёпочинят он не говорил. Просто рассказал, что это и почему. В т.ч. что совсем уж просто не починится. Впрочем, курс он читал всем известный от ПРОшников. ЗЫ и да, я без понятия, может и "починили". Я не ДБА, поэтому после уже не интересовался. ЗЗЫ ЕМНИП переход на 64 бита должен был сделать число уже совсем неприлично большим.
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Релиз СУБД PostgreSQL 17"	–2 +/–
	Сообщение от Аноним (22), 27-Сен-24, 09:19
	Вам бы на компьютерные курсы сходить чтоль, более безграмотных постов про постгрес я тут не видел
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Релиз СУБД PostgreSQL 17"	+1 +/–
	Сообщение от mos87 (ok), 27-Сен-24, 09:37
	Закрой глазки.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от нах. (?), 27-Сен-24, 09:50
	> ЗЫ и да, я без понятия, может и "починили". Я не ДБА, не надейся, у меня "настоящие" dba через стол сидят, мы как раз надысь ржали по этому поводу. > ЗЗЫ ЕМНИП переход на 64 бита должен был сделать число уже совсем А енто только в про. Покупайте наших слонов!
	Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

	30. "Релиз СУБД PostgreSQL 17"	+1 +/–
	Сообщение от Витюшка (?), 27-Сен-24, 10:21
	А ты думаешь они там просто так сидят на зарплате?
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от нах. (?), 27-Сен-24, 11:25
	> А ты думаешь они там просто так сидят на зарплате? ну могли бы книжки писать...оh..shi...
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Релиз СУБД PostgreSQL 17"	+1 +/–
	Сообщение от Аноним (33), 27-Сен-24, 11:10
	Так твой дба тоже безграмотный и все время ржёт с того случая как ему на стройке кирпич на голову упал.
	Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

	34. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (33), 27-Сен-24, 11:11
	Да и был бы он грамотным не был бы дба.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Прохожий (??), 27-Сен-24, 23:12
	У вас программисты рулят базами данных? Тады ой, беда, печаль. Мне вас искренне жаль, в общем.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Прохожий (??), 28-Сен-24, 09:03
	Типа, ты сейчас мне преподал урок логики? Раз грамотен, значит - программист, ну а если безграмотен - DBA? 🤣
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Прохожий (??), 27-Сен-24, 23:11
	А что безграмотного этот DBA сказал-то? Всё ж в доке написано. Разве нет? Счётчик идёт по кругу. Для тех случаев, когда базок в кластере много (например, для целей разработки под разных клиентов, разные версии софта) - это может стать проблемой. Понятно, что в проде столкнуться с этим сложнее. Но всё же нельзя вот так вот просто закрыть глаза на эту проблему, которая не решается уже сколько лет?
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	97. Скрыто модератором	+/–
	Сообщение от Аноним (33), 28-Сен-24, 01:30
	Зато можно поржать.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от User (??), 27-Сен-24, 12:55
	Не, ну надо же хорошим людям на чем-то зарабатывать? Вот, одна из первых продавашек астровского tantor'а: "64-битный счетчик транзакций(XID) В PostgreSQL существует ограничение (N = 232) на количество идентификаторов транзакций (XID), при достижении которого необходимо выполнить процедуру заморозки. С 64-битным XID переполнение счетчика транзакций становится фактически невозможным" покупайте-наших-слонов!
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	63. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (61), 27-Сен-24, 15:18
	А зачем этот 64-битный счётчик? Чтоб было? В практике никогда не встречал, чтобы 32-битный счётчик становился проблемой. Ну, красиво, конечно, когда он 64-битный -- тогда можно подзабить на вакуум, но если вакуум адекватно настроен, то счётчик никогда не становится проблемой.
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от User (??), 27-Сен-24, 15:53
	> А зачем этот 64-битный счётчик? Чтоб было? В практике никогда не встречал, > чтобы 32-битный счётчик становился проблемой. Ну, красиво, конечно, когда он 64-битный > -- тогда можно подзабить на вакуум, но если вакуум адекватно настроен, > то счётчик никогда не становится проблемой. Ужтыж! Аноним не встречал - и впрямь не за чем. Пойду напишу в postgres pro\tantor labs, пусть откатывают и за консультацией по настройке вакуума на опенок идут.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (61), 27-Сен-24, 16:29
	Моркентинг. 32 больше 64? Больше. Значит, лучше. Ты сам себе попробуй объяснить чем в твоём конкретном случае 32-битный счётчик будет ограничением. Если Postgres использовать, как Postgres, т.е. одна целевая БД на экземпляр, а не как Майк или "мультиарендные" версии Оракла, то 32-битного счётчика за глаза. Проблема 64-тного надуманная полностью, т.е. обычно, если экземпляр фризится из-за исчерпания счётчика, то у него и так уже масса проблем. Из-за криво настроенного вакуума, да. Ну или из-за того, что на один экземпляр навешали кучу БД с кучей транзакций.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (76), 27-Сен-24, 16:44
	У мёрзлого ежика зачем 64-битный счётчик более-менее понятно -- у них лицензия за ЭКЗЕМПЛЯР и кол-во процов. Поэтому экземпляр под каждую БД не поподнимаешь. Если на один экземпляр несколько БД (что для Слона крайне не рекомендуется, да и для Майков тоже так делать не надо), то 32-битный счётчик это печаль, да.
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

	82. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от User (??), 27-Сен-24, 17:33
	> У мёрзлого ежика зачем 64-битный счётчик более-менее понятно -- у них лицензия > за ЭКЗЕМПЛЯР и кол-во процов. Поэтому экземпляр под каждую БД не > поподнимаешь. Если на один экземпляр несколько БД (что для Слона крайне > не рекомендуется, да и для Майков тоже так делать не надо), > то 32-битный счётчик это печаль, да. Не, ну если ресурсов на каждый микросервис в каждой из сред по кластеру поднять не жалко - то можно и так, да...
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (76), 27-Сен-24, 17:55
	Postgres для микросервисов не вариант вообще. Там лайта за глаза. Если вообще нужно в реляционной схеме с данным работать. Но микросервисы это нелепое дно.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от User (??), 27-Сен-24, 18:18
	> Postgres для микросервисов не вариант вообще. Там лайта за глаза. Если вообще > нужно в реляционной схеме с данным работать. Но микросервисы это нелепое > дно. Ну, если Вы так говорите...
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (77), 27-Сен-24, 17:03
	64-разрядный счетчик хотя бы для того, чтобы на репликации у тебя вдруг колом не встал мастер, потому что реплика по какой-то причине отстала.
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	80. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (76), 27-Сен-24, 17:16
	Т.е. у тебя есть слот, реплика отвалилась на полгода, а потом, через полгода, ты решил наверстать упущенное? Ну, ок, если у тебя очень-очень много места на архив вала на это время, то что-то рациональное в этом можно усмотреть.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (76), 27-Сен-24, 17:23
	Но это же не непреодолимая проблема -- можно же настроить игнорирование слота в таких ситуациях, чтоб мастер не затупил. Хотя, ещё раз, моего воображения не хватает представить себе однобазовый экземпляр с таким кол-вом транзакций, что реплика в типичных условиях применения упиралась в счётчик.
	Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

	49. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (52), 27-Сен-24, 14:18
	Не знаю кто тебе что там обещал, но MVCC с вакуумом на данный момент не имеет аналогов по проиводительности.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	65. "Релиз СУБД PostgreSQL 17"	–1 +/–
	Сообщение от Аноним (61), 27-Сен-24, 15:20
	Ну уж так мёдом лить не надо. Реализация обслуживания mvcc в Слоне не сравнимо хуже, чем в Оракле, и, в общем, хуже, чем у Майков, но вполне себе съедобно.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (76), 27-Сен-24, 16:40
	Ну, ок, уточню -- хуже для случаев, когда транзакция COMMIT-ом завершается, но лучше, когда ROLLBACK-ом. Это если только производительность именно данной конкретной функциональности в отрыве от прочих накладных расходов рассматривать. Всё же сохранять хронологические данные вместе в оперативными прикладными хоть и быстро, но уж очень имеет тенденцию пухнуть. Даже если вакуум адекватный, но всё равно оракловые UNDO и майковое VERSION STORE в TempDB лучше. На мой взгляд. Но и решением Слона вполне можно жить.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Прохожий (??), 27-Сен-24, 23:15
	Rollback намного более редкая ситуация на практике, чем Commit.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (61), 27-Сен-24, 15:14
	нах, тебе-то чем вакуум не угодил?
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	93. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Прохожий (??), 27-Сен-24, 23:19
	Тем, что это убогая технология, которая может (не обязательно, но случаев много) повлечь за собой кучу проблем. Сейчас, конечно, с ним получше стало, чем N лет назад. Но всё равно, любой commit - это тормоза по определению из-за вот этого способа сохранять старые данные. Плюс отсутствие масштабирования. У Oracle UNDO можно положить на другую дисковую подсистему. С PG так не получится, разве что отдельные таблицы раскидывать по этим подсистемам. Плюс таблицы регулярно пухнут. И получается, для часто изменяемых таблиц без vacuum - никак. Особенно, если эти таблицы в отчётности какой ещё участвуют. Ведь не почистишь таблицу, придётся (если полное сканирование) перелопачивать все данные, в том числе старые, которые уже никому не нужны ни в каком виде.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Наме (?), 28-Сен-24, 11:52
	Никаких тормозов фиксация в Слоне не подразумевает. В Слоне фиксация очень простая операция. С остальным, скорее, согласен. Файлы данных в Слоне пухнут, да. Пухнут даже при нормально настроенном вакууме. До сих пор нет онлайнового полного вакуума. И это реальная, а не надуманная проблема.
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Прохожий (??), 29-Сен-24, 11:16
	Разумеется, сам по себе commit - быстрая операция. Но подготовка к нему, особенно, когда данных меняется много и разнести ввод-вывод (в отличие от Оракла) никак нельзя, потому что всё in-place...
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Наме (?), 29-Сен-24, 23:57
	Ну почему нельзя-то? Расслоить вв ничто не мешает. И у Слона нет изменений инплэйс никогда, кроме тостов. Это со временем и становится проблемой.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (119), 30-Сен-24, 12:45
	>До сих пор нет онлайнового полного вакуума. И это реальная, а не надуманная проблема. Есть, но через расширение. https://reorg.github.io/pg_repack/ Костыльно, всрато, но работает.
	Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

5. "Релиз СУБД PostgreSQL 17"	+/–
Сообщение от Цезий Родонович (?), 26-Сен-24, 21:01
UNOD пока не завезли, тогда пофиг будем на любом postgresql
Ответить | Правка | Наверх | Cообщить модератору

6. "Релиз СУБД PostgreSQL 17"	+3 +/–
Сообщение от Аноним (6), 26-Сен-24, 21:06
>в течение пяти лет Вот интересно как тут влияет длительность поддержки. Рейтинг популярности СУБД: https://db-engines.com/en/ranking
Ответить | Правка | Наверх | Cообщить модератору

	8. Скрыто модератором	–3 +/–
	Сообщение от голос из леса (?), 26-Сен-24, 21:39
	"their popularity" What is it? Next bullshit?
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Релиз СУБД PostgreSQL 17"	+1 +/–
	Сообщение от Bonbon (?), 26-Сен-24, 21:46
	Почему МарияДБ сползла в подвал?
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	10. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (10), 26-Сен-24, 22:22
	Потому как время форумов и баз для сайтов прошло.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Релиз СУБД PostgreSQL 17"	–2 +/–
	Сообщение от Аноним (15), 27-Сен-24, 07:08
	Фанатики форсили, но на практике мускл намного более полноценный продукт.
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	41. "Релиз СУБД PostgreSQL 17"	–1 +/–
	Сообщение от Аноним (33), 27-Сен-24, 11:48
	На практике одно и то же. И нет смысла переходить на Марию.
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Ilya Indigo (ok), 28-Сен-24, 04:35
	На практике, Мария хуже Мускуля! Так как есть в ней моменты, которые после форка в мускуле исправили а в Марие до сих пор нет. И JSON через жопу в ней реализовали. Если у вас типичный сайт на вордпрессе или другой CMS или сайт на каком-нибудь фреймвёрке с моделью PDO, то разницы, практически не будет. Но если вы инженер и вы разрабатываете сложную структуру, которая будет завязана на СУБД, и вы сравниваете различия между ними, то результат выбора очевиден в пользу MySQL.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от _ (??), 29-Сен-24, 22:49
	... то результат выбора очевиден в пользу PostgreSQL Исправил, не благодари!(С)
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Релиз СУБД PostgreSQL 17"	–1 +/–
	Сообщение от Ilya Indigo (ok), 30-Сен-24, 07:23
	> ... то результат выбора очевиден в пользу PostgreSQL > Исправил, не благодари!(С) Да не за что, могу и постгресс разобрать! 1 Постгрессчики часто хвалятся поисковой системой. У MySQL InnoDB тоже есть полнотекстовый поиск, который даже проще в использовании и вполне годен для простого использования (нагрузка на поиск не большая). Если же нужен поиск с большой нагрузкой, то MySQL+Shinx уделывает его. 2 Постгрессу c кучей разных типов полей неводом тип unsigned (tiny,small,medium)int. А типы tinyint и mediumint вовсе не ведомы! То есть если мне нужно битовое поле, то на каждое придётся выделять 2 байта вместо 1! Сохранить компактно unix timestamp и crs32 в 4 байтах в unsigned int не получится, ведь его там нет! Используй 8 бит вместо 4! 3 Жрать память постгрес любит, просо обожает! На проекте БД в несколько ТБ и вышла свежая версия 17, здорово было бы обновится? На MySQL это не составит никакого труда, ну естественно бекапы никто не отменял, там миграция данных к новой версии или вообще не нужна или выполняется быстро и автоматически! А вот постгресс БД в несколько ТБ ты не обновишь, они НЕ совместимы между версий! Ты должен сделать именно текстовый бэкап, так как физическая репликация и бинарный бэкап НЕ совместимы между разных версий! И или ты вечно должен быть на старой версии или использовать только текстовый логический бэкап, который будет весить уже десятки Тэр каждый! И перейти на свежую версию практически невозможно! Так как очень долго, трудно, и высока вероятность накосячить из-за сетевого сбоя! В MySQL такой проблемы нет и никогда не было! 4 Сама идея версионности, в которой ты изменяешь данные, и старые не перестают существовать, как в MySQL, а создаётся копия данных, которая существует паралельно с новой, и при каких-то обстоятельствах может быть даже прочитана, и нужен запуск вакуума чтобы, её очистить, просто кажется каким-то безумием! 5 У MySQL каждый тип поля строго ограничен! Это позволяет как более эффективно использовать место, так и разработчика задумываться о выделении максимального размера под данные и их проверку и валидацию! У постгресса же есть очень распространённый тип text, который ограничен только файловой системой и я видел много кода, в котором вообще проверки на размер данных нету они всё что пришло в посте от пользователя тупо помещают в поля с типом text без каких-либо проверок! 6 У MySQL есть несколько движков, в особенности MyISAM, скорость вставки в который в 16 раз выше, чем в постгресс и InnoDB! Была у меня задача по аналитике, где каждый раз по запросу аналитика нужно обработать данные от огромных нескольких таблиц с предложениями и спросами и сформировать результирующую таблицу в удочитаемом формате. На MySQL MyISAM мой код выполнялся в 16 раз быстрее, чем написанный на постгрессе! 7 Ну и ещё мелочь вспомнил, когда я модифицирую таблицу в MySQL я могу добавить новое поле в любое место таблицы, хоть в самое начало, но в постгрессе я могу добавить поле лишь в самый конец! Из всего изложенного я давно понял, что в типичных web-приложениях с одним основным пользователем БД, MySQL лучший выбор! Он быстрее, гибчеб эффективнее, надёжнее и легче в ослуживании!
	Ответить | Правка | Наверх | Cообщить модератору

	118. "Релиз СУБД PostgreSQL 17"	–1 +/–
	Сообщение от Аноним (61), 30-Сен-24, 12:42
	Хорошее подтверждение пословицы про меньше знаешь, лучше спишь. Если на твоём уровне восприятия, то Инно очень мало, чем отличается от Слона. В бесплатном, т.е. самой массовом, виде в Инно намерено и предупреждая об этом забили на ряд проблем с надёжностью сохранения данных в случаях аварийного сбоя экземпляра, в Слоне с этим проблемы нет. MyISAM это вообще не СУБД, а просто ненадёжная строковая хранилка (чтобы ты понял что-то вроде эксэльки), поэтому и быстрая, потому что целостность данных никак не обеспечивается вообще. Когда понимаешь, что к чему, этот баг может быть и фичей (например, при регистрации не слишком ценных данных, когда некоторые потери допустимы), но ты всё равно не понимаешь, поэтому просто рискуешь потерять данные...
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Релиз СУБД PostgreSQL 17"	+1 +/–
	Сообщение от Bkmz (??), 27-Сен-24, 09:49
	Не знаю, как мария, в РФ на мой взгляд в основном набирает популярность postgresql мне во многих компаниях говорили, что они отказываются от mssql или oracle, и двигаются в сторону postgres
	Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

	46. "Релиз СУБД PostgreSQL 17"	–1 +/–
	Сообщение от slowkun (ok), 27-Сен-24, 13:34
	В тех компаниях, что я работал, как сидели так и сидят на mssql. И двигаться там куда-то они не собираются по причине - руководство эти ваши постгресукеелы не знает и знать не велит.
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от 1 (??), 27-Сен-24, 15:11
	"Заставляют отказываться" ... И таки да - пытаются заменить ... Но замена неравнозначная ... Не знаю про Oracle - но при замене MS SQL скорость деградирует в разы. Причём, если для 1с ЗУиП скорость хоть как-то довели до приемлемого уровня, то для крупняка, типа адванты, нет.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	71. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (61), 27-Сен-24, 15:42
	Там проблема в 1С, а не в СУБД. Изначально пилили под блокировщик и грязное чтение, поэтому теперь и проблемы с Postgres, в котором грязного чтения нет в принципе.
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Илья (??), 27-Сен-24, 18:05
	> Но замена неравнозначная Вот заиспользуют все самые специфичные мутные фичи от БД, а потом за голову хватаются.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	67. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (61), 27-Сен-24, 15:28
	Оракл и Майк не купить.
	Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

	25. "Релиз СУБД PostgreSQL 17"	–1 +/–
	Сообщение от Аноним (25), 27-Сен-24, 09:46
	> Рейтинг популярности СУБД Что там делает монго?
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	27. "Релиз СУБД PostgreSQL 17"	–2 +/–
	Сообщение от neo one (?), 27-Сен-24, 09:47
	>Что там делает монго? ворочает терабайтами ) причём уж побыстрее кое-кого, не будем пальцами показывать.
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (33), 27-Сен-24, 11:17
	Это та сама монга которая не в состоянии сделать самый примитивный джоин? Такая база только для смузиков.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от нах. (?), 27-Сен-24, 11:27
	>>Что там делает монго? > ворочает терабайтами ) причём уж побыстрее кое-кого, не будем пальцами показывать. нуууу фффцелом... зашифровать нафиг всю тазу банных какого-нибудь особо модного-современного-облачного ентер-прайса у нее действительно сильно побыстрее многих выходило. (подскажите, эксперты - у нее по прежнему дефолтная конфигурация без авторизации вовсе, да?)
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	40. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (33), 27-Сен-24, 11:41
	По умолчанию вход только с локалхоста без авторизации.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от нах. (?), 27-Сен-24, 13:06
	> По умолчанию вход только с локалхоста без авторизации. и кому оно нужно такое умолчание? К тому же это скорее всего - настройка твоего дистрибутива, чтоб ты пое...лся лишний раз.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (33), 27-Сен-24, 14:24
	Я с сайта ставил по официальной доке https://www.mongodb.com/docs/manual/tutorial/install-mongodb.../
	Ответить | Правка | Наверх | Cообщить модератору

	66. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (61), 27-Сен-24, 15:25
	Давно сдохла. Его крупняк везде выпиливает. С огромным трудом и затратами.
	Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

	58. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от 1 (??), 27-Сен-24, 15:07
	R:Base приподнялся ... Ах - где мои 17 лет и красный сарафан ?
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

24. "Релиз СУБД PostgreSQL 17"	–2 +/–
Сообщение от neo one (?), 27-Сен-24, 09:43
>Расширены возможности SQL-команды "MERGE", позволяющей создавать условные SQL-выражения, объединяющие в одном выражении операции INSERT, UPDATE и DELETE. Вау, изобрели то что было было в монге 2.х 10 лет назад.
Ответить | Правка | Наверх | Cообщить модератору

	113. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Rollo99 (ok), 29-Сен-24, 13:01
	Не изобрели, а пробили и протащили в релиз. Теме почти 20 лет ) https://habr.com/ru/companies/postgrespro/articles/412605/
	Ответить | Правка | Наверх | Cообщить модератору

26. "Релиз СУБД PostgreSQL 17"	–2 +/–
Сообщение от neo one (?), 27-Сен-24, 09:46
>Реализована поддержка новых возможностей для работы с форматом JSON, определённых в стандарте SQL/JSON SQL/JSON - это тупиковый путь, натягивать JSON в SQL. Посмотрели бы как в монге сделана работа с JSON - очень удобно.
Ответить | Правка | Наверх | Cообщить модератору

	31. "Релиз СУБД PostgreSQL 17"	+1 +/–
	Сообщение от Golangdev (?), 27-Сен-24, 10:36
	> SQL/JSON - это тупиковый путь нет, попробуй поработать в реальных большию компаниях, увиденное тебя удивит
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Релиз СУБД PostgreSQL 17"	+1 +/–
	Сообщение от Аноним (33), 27-Сен-24, 11:15
	Работал я в одной компании так там золотым микроскопом шурупы забивают в бетонную стену. Увиденного хватило.
	Ответить | Правка | Наверх | Cообщить модератору

	47. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от neo one (?), 27-Сен-24, 14:13
	>попробуй поработать в реальных большию компаниях, увиденное тебя удивит да я в курсе, переходят на 1С и поц^WТантор ) мне хорошо в маленькой компании, где я сам себе техлид )
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	48. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от neo one (?), 27-Сен-24, 14:14
	>попробуй поработать в реальных большию компаниях а ещё натягивают на свой любимый SQL всякие уродства типа Hibernate или JUKE, чтобы поменьше тошнило. А просто взять изначально объектную СУБД дядя-насяльника не велит )
	Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

	51. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (51), 27-Сен-24, 14:19
	Начнём с того, что в огромной куче задач тебе вообще не нужна субд.
	Ответить | Правка | Наверх | Cообщить модератору

	54. Скрыто модератором	+1 +/–
	Сообщение от Аноним (52), 27-Сен-24, 14:24
	А продолжим тем, что в другой огромной куче нужна.
	Ответить | Правка | Наверх | Cообщить модератору

	55. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (33), 27-Сен-24, 14:28
	Поэтому для этих задач мы напишешь хранимых процедур и будем их поддерживать.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	64. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от 1 (??), 27-Сен-24, 15:20
	Для каждого болта свой молоток. Где-то нужна объектная СУБД, а где-то и ClickHouse самое оптимальное.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	70. "Релиз СУБД PostgreSQL 17"	–1 +/–
	Сообщение от Аноним (61), 27-Сен-24, 15:34
	Их нет, "объектных" СУБД. На рынке только реляционные остались. Остальное -- не нужно.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Прохожий (??), 27-Сен-24, 23:24
	Есть. Oracle.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Наме (?), 28-Сен-24, 11:56
	Нет, Оракл ни разу не объектная СУБД.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Прохожий (??), 29-Сен-24, 11:18
	Лень искать их рекламные проспекты N-летней давности.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Релиз СУБД PostgreSQL 17"	–1 +/–
	Сообщение от Аноним (61), 27-Сен-24, 15:32
	Объектных СУБД не существует в природе. Рабочих.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

	79. "Релиз СУБД PostgreSQL 17"	–1 +/–
	Сообщение от 1 (??), 27-Сен-24, 17:07
	А что, MUMPS и его наследник Cache сдохли ? И что там было у межделмаша в AS/400 ?
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (61), 30-Сен-24, 12:55
	Это не "Объектные СУБД", а в нынешнем понимании что-то вроде Ф/С с COW. Ну вот какой-нибудь ZFS. Только с исходно аппаратными подходами к обеспечению надёжности сохранения данных. "Объектных" СУБД не существует не потому что я этого не хочу признавать, а потому что это не пойми что, т.е. нет набора критериев, которые бы позволяли сказать, что вот это вот перед нами объектная СУБД, а не фиг пойми что. Вот есть куда более понятный пример той же Монги или хранения ясончиков в блобах. Но то, что там неким образом сериализованные "объекты" хранятся не делает хранилку СУБД, потому что единообразно манипулировать информацией этих объектов возможности нет. Да и что такое -- объект? Классическое определение это экземпляр типа, т.е. нечто материализованное в памяти. Но для, скажем, Джавы это будет одно, а вот для JS -- совсем-совсем другое. Нет единого определения нет и теории со счислением. А для реляционки -- есть. И отображение объектов в реляционку проблема исключительно надуманная.
	Ответить | Правка | Наверх | Cообщить модератору

	94. "Релиз СУБД PostgreSQL 17"	–1 +/–
	Сообщение от Прохожий (??), 27-Сен-24, 23:24
	Oracle. Вполне себе объектная СУБД по совместительству. Рабочая.
	Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

107. "Релиз СУБД PostgreSQL 17"	+/–
Сообщение от Аноним (107), 28-Сен-24, 15:10
В каждую радужную ветку про постгре надо заносить ссылки примерно такие https://www.linux.org.ru/news/opensource/17209306?cid=17209869 и дальше по обсуждению. Эту ветку https://www.linux.org.ru/news/proprietary/17234705#comments Что-то такое https://www.linux.org.ru/news/opensource/17652488?cid=17652756 И просто поискать по всему лор. Тут то очки и спадут.
Ответить | Правка | Наверх | Cообщить модератору

121. "Релиз СУБД PostgreSQL 17"	+/–
Сообщение от анонимус (??), 01-Окт-24, 01:58
Будет ли в новой версии работать такой запрос? SELECT file AS b FROM files ORDER BY SUBSTR(b, 6); В 15 не работает.
Ответить | Правка | Наверх | Cообщить модератору

	122. "Релиз СУБД PostgreSQL 17"	+/–
	Сообщение от Аноним (61), 01-Окт-24, 12:50
	Со Слоном работаю с 9-той версии. И такое всегда работало. И сейчас прекрасно работает.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема