forum.opennet.ru - "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" (57)

"Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"

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

"Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
Сообщение от opennews (??), 09-Май-19, 23:28
Сформированы (https://www.postgresql.org/about/news/1939/) корректирующие обновления для всех поддерживаемых веток PostgreSQL: 11.3 (https://www.postgresql.org/docs/current/static/release-11-3....), 10.8 (https://www.postgresql.org/docs/current/static/release-10-8....), 9.6.13 (http://www.postgresql.org/docs/current/static/release-9-6-13...), 9.5.17 (http://www.postgresql.org/docs/current/static/release-9-5-17...) и 9.4.22 (http://www.postgresql.org/docs/current/static/release-9-4-22...), в которых представлена порция исправлений ошибок. Выпуск обновлений для ветки 9.4 продлится (http://www.postgresql.org/support/versioning/) до декабря 2019 г., 9.5 до января 2021 г., 9.6 - до сентября 2021 года, 10 - до октября 2022 года, 11 - до ноября 2023 года. В новых версиях исправлено более 60 ошибок и устранено четыре уязвимости: - Две уязвимости (CVE-2019-10127, CVE-2019-10128) специфичны для уплатформы Windows и проявляются в инсталляторах от компаний EnterpriseDB и BigSQL, которые не выставляли надлежащих прав доступа на каталог с данными, что позволяло любому непривилегированному пользователю Windows инициировать выполнение кода на уровне сервиса PostgreSQL. - Уязвимость CVE-2019-10129 проявляется в PostgreSQL 11 и позволяет пользователю прочитать произвольные области памяти серверного процесса через отправку специально оформленного запроса INSERT к партицированной таблице. - Уязвимость CVE-2019-10130 позволяет прочитать значения записей, к которым ограничен доступ. Из исправленных ошибок можно отметить повреждение каталога при выполнении "ALTER TABLE" над партицированной таблицей, крах сервера при возникновении ошибки при попытке сохранения курсора между подтверждениями транзакции, проблемы с производительностью при откате транзакций, охватывающих большое число таблиц, отсутствие поддержи выражения "CREATE TABLE IF NOT EXISTS .. AS EXECUTE ..", утечки памяти. URL: https://www.postgresql.org/about/news/1939/ Новость: https://www.opennet.dev/opennews/art.shtml?num=50660
Ответить \| Правка \| Cообщить модератору

Оглавление

Объясните мне, почему столько веток у него А также вопрос к тем, кто давно юзае, Аноним (1), 23:28 , 09-Май-19, (1) –1

Посмотрите темку в нете почему Uber ушел с постгреса на мускл А вообще подбешива, хотел спросить (?), 00:34 , 10-Май-19, (3) –11

Тащем-то в мыскле тоже наличествует свой вакуум, который время от времени тоже н, Аноним (19), 18:02 , 10-Май-19, (19)

Штэ , Онаним (?), 20:35 , 10-Май-19, (23)

OPTIMIZE TABLE table_name Не знал Фанбои мыскля еще много чего про свой фетиш н, Аноним (19), 04:59 , 11-Май-19, (34) +3

Какой ещё MyISAM Все давно используют InnoDB А для тех кто всё же поленился пр, zekefast (ok), 00:15 , 11-Май-19, (26)

Спасибо посмеялся InnoDB сразу данные удаляет Только недавно делал на базе с н, Дима (??), 17:35 , 11-Май-19, (41)

Я не говорил о моментальном удалении данных Я говорил о том, что механизм UNDO , zekefast (ok), 00:47 , 12-Май-19, (44)

Сильно зависит от нагрузок UNDO в стиле Oracle, грубо говоря, удваивает объем вы, DeadMustdie2 (?), 11:19 , 12-Май-19, (46)

Ну если грубо говоря, то учетверяет Пишем журнал- undo- журнал- обновленную зап, КО (?), 10:34 , 13-Май-19, (48)

О Капитан, уточните, какие из трёх указанных running service или как бы это , Andrey Mitrofanov (?), 10:57 , 13-Май-19, (49)

Да Оптимистично только журнал Но это при условии что нагрузка нерегулярная и и, КО (?), 09:36 , 18-Май-19, (58)

Удваивает запись в журнал - т е синхронную запись, которая напрямую влияет на, DeadMustdie2 (?), 11:08 , 13-Май-19, (50) +1

Тут такое дело, VACUUM в PG дело добровольное И если его не дергать, то он ни н, Аноним (19), 16:52 , 12-Май-19, (47)

Причём таблица блокируется полностью, Дима (??), 17:36 , 11-Май-19, (42) +1

Если не просто посмотреть, а ещё и почитать, то можно увидеть, что Uber, фактиче, Аноним (24), 20:35 , 10-Май-19, (24)

Так скакать с ветки на ветку не все умеют одинаково хорошо PS ушло в репозитори, Michael Shigorin (ok), 02:21 , 10-Май-19, (6) –7

А почему у них должны возникать проблемы Оно настолько безоглядно разрабатывает, Константавр (ok), 07:47 , 10-Май-19, (9) –2

До 10-й версии мажорными считались релизы 9 x минорными 9 x y, как уже сказали, , Аноним (10), 08:06 , 10-Май-19, (10) +2
Непонятно что вас смущает в LTS, это же стандартная практика для серьёзного софт, Аноним (20), 19:03 , 10-Май-19, (20)

Потому что это секьюрити-фиксы И потому что в постгресе нет бинарной совместимо, Аноним (8), 02:53 , 10-Май-19, (8)
Его главное отличие от MariaDB, MySQL, Percona - он один Все чаще наблюдаю карт, Аноним (10), 08:11 , 10-Май-19, (11) +3

Мне кажется, что Оракл специально реализует фичи из MariaDB с другим синтаксисом, KonstantinB (ok), 00:39 , 11-Май-19, (28)

Да это как-то однопенисно Вот то, что они уже пилят две разные несовместимые кл, Аноним (19), 04:54 , 11-Май-19, (33)

ну так он вызван изначальной глупостью - пытаться вместо чистого форка сделать d, нах (?), 13:26 , 14-Май-19, (51)

В рамках данной дискуссии ваш вопрос относится скорее к категории религиозных Пр, Аноним (14), 10:01 , 10-Май-19, (14)

бросьте, вот только что приходил товарисч, взгромоздивший на постгрез zabbix В , нах (?), 13:32 , 14-Май-19, (53)

Разрабам не лень их поддерживать, а может их спонсируют организации использующие, Ilya Indigo (ok), 12:49 , 10-Май-19, (16) –6

В 12-й релиз запилили API для новых типов storage engine, новые сторажи завезут , Catwoolfii (ok), 21:14 , 10-Май-19, (25) +2

То есть ещё очень не скоро и ещё не известно как эти новые типы себя поведут и с, Ilya Indigo (ok), 00:59 , 11-Май-19, (31)

Тю Вот у меня есть таблица users, в которой есть email и поле deleted_at, которо, KonstantinB (ok), 00:36 , 11-Май-19, (27) –1

Текстовые поля вообще не нужно индексировать без крайней на то необходимости, да, Ilya Indigo (ok), 00:57 , 11-Май-19, (30) –1

Ууууу Скажите, а где вы работаете Ну так, чтобы случайно туда не обратиться , KonstantinB (ok), 11:38 , 11-Май-19, (36) +1

Единственное в чем выигрывает Mysql и его подобия это простота администрирован, GentooBoy (ok), 02:08 , 11-Май-19, (32)

MySQL также можно подогнать под нужды и настроить там что угодно, хоть кэш отклю, Ilya Indigo (ok), 12:07 , 11-Май-19, (37)
Простота администрирования - в базовых случаях да А тонкий тюнинг innodb - это , KonstantinB (ok), 14:37 , 11-Май-19, (40)

если тебе понадобился тонкий тюнинг innodb - посгрез на этом же железе на той же, нах (?), 13:35 , 14-Май-19, (54)

кое-как добиться почти такой же производительности и надежности, как у mysql из , нах (?), 13:27 , 14-Май-19, (52) –1

Это в смысле когда база мыскля вдруг тупо впадает в задумчивость и оживает тольк, Аноним (57), 06:19 , 15-Май-19, (57)

Классика же, ну https grimoire ca mysql choose-something-else, киця (?), 13:42 , 10-Май-19, (17)
потому что более энтерпрайзен, это как Oracle 11, 12, 2018 , Аноне (?), 19:43 , 10-Май-19, (21)

10й postgres уже готов для продакшена, порекомендовать можете , Аноним (4), 00:41 , 10-Май-19, (4) –1

Юзаем 11, проблем особых не испытываем , Аноним (14), 09:55 , 10-Май-19, (13) +1

Тоже 11 в проде, ОЛЕГ (?), 22:02 , 14-Май-19, (55) +1

10-й в яндексе используютhttps cloud yandex ru docs managed-postgresql qa post, rshadow (ok), 10:29 , 10-Май-19, (15) –1
Давно готов Уже и на 11-м полет нормальный , KonstantinB (ok), 00:41 , 11-Май-19, (29)

И cтоит ли ради всех фич логической репликации апдейтиться с 9 6 до 10 8 , Аноним (4), 00:49 , 10-Май-19, (5) –3

Если эти фичи вам нужны, то стоит Если не нужны - то не стоит , Капитан Очевидность (?), 02:50 , 10-Май-19, (7) +6
Если все устраивает на текущей ветке, то смысле дергаться до осень 21-го года не, Аноним (10), 08:12 , 10-Май-19, (12) –1
Ради параллельных вычислений на 11 стоит, ОЛЕГ (?), 22:03 , 14-Май-19, (56) –1

Где-то плачет один Аноним755 , Аноним (18), 15:13 , 10-Май-19, (18)
Ребят, а какие линуксовые среды разработки есть годные под него типа PL SQL Dev, Аноне (?), 19:48 , 10-Май-19, (22) –2

vim, emacs, Аноним (35), 10:12 , 11-Май-19, (35)

ed жеж, почти edge, Аноним (38), 13:14 , 11-Май-19, (38)

В общем, загуглил, но хотел узнать чем здешние люди пользуются для разработки на, Аноне (?), 13:40 , 11-Май-19, (39)

- А чем вы гладите тонкое женское белье - А чем ВЫ гладите тонкое женско, Аноним (14), 22:23 , 11-Май-19, (43)
Насчет оркела не знаю, но и для постгреса, и для мыскля мне более чем хватает da, KonstantinB (ok), 06:14 , 12-Май-19, (45) +1

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

1. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" –1 +/–

Сообщение от Аноним (1), 09-Май-19, 23:28

Объясните мне, почему столько веток у него? А также вопрос к тем, кто давно юзает и разбирается, какие преимущества и в чем существенные отличия от MySQL/MariaDB? Благодарю заранее.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" –11 +/–

Сообщение от хотел спросить (?), 10-Май-19, 00:34

Посмотрите темку в нете почему Uber ушел с постгреса на мускл.
А вообще подбешивают таблицы большими буквами и т.д.
В посгресе дофига плагинов. Есть говновакуум.. в общем пока не попробуешь под свои задачи - непонтяно, что лучше он или MySQL. Я за последний.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

19. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Аноним (19), 10-Май-19, 18:02

Тащем-то в мыскле тоже наличествует свой вакуум, который время от времени тоже надо применять на движках сложнее MyISA.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

23. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Онаним (?), 10-Май-19, 20:35

Штэ?

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

34. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +3 +/–

Сообщение от Аноним (19), 11-Май-19, 04:59

OPTIMIZE TABLE table_name;
Не знал? Фанбои мыскля еще много чего про свой фетиш не знают. И прямую ложь про "нет вакуума" двадцать лет всем в уши дуют.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

26. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от zekefast (ok), 11-Май-19, 00:15

Какой ещё MyISAM? Все давно используют InnoDB. А для тех кто всё же поленился пройти по указанным материалам от Uber-a и смежным докладам, даже русскоязычных докладчиков... У InnoDB табличный движок более хорошо приспособлен для определённых типов операций и постоен на UNDO таблице в которую помещаются данные колонок обновлённых записей на которые ещё есть открытые транзакции. Как следствие этого при закрытии транзакций и репликации данные можно просто удолить из этой специальной таблицы без порождения фрагментации данных в таблице на диске.
Движок PostgreSQL копирует обновлённую запись, а старую помечает, как удалённую. Новые транзакции пускаются на новую запись, а старая завершает обслуживание уже начатых транзакций. Как следствие, старые записи надо вычищать для чего и служит механизм VACUUM. Но при больших нагрузках и частых записях возникает проблема, так как процесс VACUUM более ресурсоёмкий чем чистка отдельной таблицы UNDO. Так же как следствие подобной организации работы с данными является разница в качестве работы репликации в этих базах и по сути невозможность master-master репликации для PostgreSQL. Если в 11 версии ничего не поменялось. Не смотрел её ещё.
In a nutshell...

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

41. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Дима (??), 11-Май-19, 17:35

Спасибо посмеялся. InnoDB сразу данные удаляет? Только недавно делал на базе с ним чистку, так после OPTIMIZE TABLE база похудела на 50 гиг. Причём делался он ну очень, очень долго.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

44. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от zekefast (ok), 12-Май-19, 00:47

> Спасибо посмеялся. InnoDB сразу данные удаляет? Только недавно делал на базе с
> ним чистку, так после OPTIMIZE TABLE база похудела на 50 гиг.
> Причём делался он ну очень, очень долго.
Я не говорил о моментальном удалении данных. Я говорил о том, что механизм UNDO более дешёвый с точки зрения производительности чем механизм VACUUM при котором надо сканить таблицы и что-то делать с фрагментацией данных.

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

46. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от DeadMustdie2 (?), 12-Май-19, 11:19

> механизм UNDO более дешёвый с точки зрения производительности чем механизм VACUUM
Сильно зависит от нагрузок.
UNDO в стиле Oracle, грубо говоря, удваивает объем выполняемой записи в журнал - потому что его надо тоже защищать REDO.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

48. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от КО (?), 13-Май-19, 10:34

>Oracle, грубо говоря, удваивает объем выполняемой записи в журнал
Ну если грубо говоря, то учетверяет. Пишем журнал->undo->журнал->обновленную запись.
В PG 3 : журнал->новая->пометка старой
У Oracle  выигрыш в использовании места (а соответственно быстрее full scan) на частых update, но и chained rows как следствие.

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

49. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Andrey Mitrofanov (?), 13-Май-19, 10:57

> В PG 3 : журнал->новая->пометка старой
О! Капитан, уточните, какие из трёх указанных "running service" (или как бы это назвать -- запущенный сервис с кешом (("мастер", реплики вообще не интересны--)) в озу) таки-да _не_ пишет на диск  _вне чекпоинтов_.
Мне всегда это было интересно, но всё никак не могу разобраться до конца.
Есть "оптимистичное" предположение, что не пишутся при указанных условиях 2 из 3-ёх.  Но есть смутные сомнения, что условия не все или не те...   Требуется помощь очевидных войск...   ?

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

58. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от КО (?), 18-Май-19, 09:36

> Есть "оптимистичное" предположение,
Да. Оптимистично только журнал. Но это при условии что нагрузка нерегулярная и иногда дает покурить. А если постоянная и на максимуме, как в свое время в Сбере, то в какой-то момент времени выясняется, что терабайт памяти пишется на диск не моментально, а если запаниковать, то его еще из журналов восстанавливать надо, что тоже не  ускоряет процесс.

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

50. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +1 +/–

Сообщение от DeadMustdie2 (?), 13-Май-19, 11:08

>>Oracle, грубо говоря, удваивает объем выполняемой записи в журнал
> Ну если грубо говоря, то учетверяет. Пишем журнал->undo->журнал->обновленную запись.
Удваивает *запись в журнал* - т.е. синхронную запись, которая напрямую влияет на скорость выполнения.
Вся остальная запись асинхронная, и влияние её косвенное (увеличивает количество IOPS, но при этом хорошо параллелится и не блокирует дальнейшие действия приложения).

> В PG 3 : журнал->новая->пометка старой
> У Oracle  выигрыш в использовании места (а соответственно быстрее full scan)
> на частых update, но и chained rows как следствие.
Алгоритмы Oracle сокращают фрагментацию основного табличного пространства ценой двойной фиксации изменений: в основное табличное пространство и в UNDO.

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

47. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Аноним (19), 12-Май-19, 16:52

Тут такое дело, VACUUM в PG дело добровольное. И если его не дергать, то он ни на что не влияет. И получается так, что у мыскля с его UNDO производительность только съедается впустую. И да, если в мыскле применить аналог vacuum'а, то таблицы лочатся намертво.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

42. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +1 +/–

Сообщение от Дима (??), 11-Май-19, 17:36

Причём таблица блокируется полностью

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

24. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Аноним (24), 10-Май-19, 20:35

>Посмотрите темку в нете почему Uber ушел с постгреса на мускл.
Если не просто посмотреть, а ещё и почитать, то можно увидеть, что Uber, фактически, реализует файловую систему поверх SQL, для чего MySQL внезапно подходит значительно лучше именно благодаря своей примитивности.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" –7 +/–

Сообщение от Michael Shigorin (ok), 10-Май-19, 02:21

Так скакать с ветки на ветку не все умеют одинаково хорошо.
PS: ушло в репозиторий sisyphus_e2k ещё утром 9 мая.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

9. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" –2 +/–

Сообщение от Константавр (ok), 10-Май-19, 07:47

А почему у них должны возникать проблемы? Оно настолько безоглядно разрабатывается, что даже в рамках девятой версии аж три ветки приходится поддерживать? Это базы данных-то? Офигеть.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

10. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +2 +/–

Сообщение от Аноним (10), 10-Май-19, 08:06

До 10-й версии мажорными считались релизы 9.x минорными 9.x.y, как уже сказали, между мажорными версиями нет бинарной совместимости файлов, и весьма разный набор фич.
Начиная с 10-й версии схему привели к общепринятому виду, убрав лишнюю цифру из версии.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

20. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Аноним (20), 10-Май-19, 19:03

Непонятно что вас смущает в LTS, это же стандартная практика для серьёзного софта.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

8. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Аноним (8), 10-Май-19, 02:53

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

11. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +3 +/–

Сообщение от Аноним (10), 10-Май-19, 08:11

Его главное отличие от MariaDB, MySQL, Percona - он один. Все чаще наблюдаю картину, когда компоненты работающие в рамках одного проекта ранее спокойно жили вместе на одной БД на мыскле, теперь могут начинать конфликтовать из-за того, что кто-то хочет фичи от MariaDB а кому-то подавай ортодоксальный MySQL от оракакеля. И чем дальше, тем разломы между фактически одной и той же СУБД только расширяются и углубляются. Что тут скажешь, фанбои мыскля сами выбрали свой путь страдания.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

28. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от KonstantinB (ok), 11-Май-19, 00:39

Мне кажется, что Оракл специально реализует фичи из MariaDB с другим синтаксисом, чтобы усложнить миграцию.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

33. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Аноним (19), 11-Май-19, 04:54

Да это как-то однопенисно. Вот то, что они уже пилят две разные несовместимые клиентские библиотеки, вот это п....ц и Израиль.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

51. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от нах (?), 14-Май-19, 13:26

ну так он вызван изначальной глупостью - пытаться вместо чистого форка сделать drop-in replacement. В результате совместимость все равно поломана, но вот удержать на одном хосте две разные - теперь неприемлемый геморрой (слава виртуалочкам, что уже низачем и не нужно)

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

14. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Аноним (14), 10-Май-19, 10:01

> какие преимущества и в чем существенные отличия от MySQL/MariaDB?
В рамках данной дискуссии ваш вопрос относится скорее к категории религиозных.
Преимущества и недостатки имеют все перечисленные системы. Для админа локалхоста/конторы до 1000 юзеров вообще никакой разницы, кроме той, что MySQL везде, где заявлена/требуется БД всунут по умолчанию, а для использования вместо него PostgreSQL придется приложить некие минимальные дополнительные усилия.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

53. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от нах (?), 14-Май-19, 13:32

бросьте, вот только что приходил товарисч, взгромоздивший на постгрез zabbix. В конторе до 1000 и никто его не заставлял.
(ну да, ну да - с его бесконечными поштучными insert, запросами where ... in ( ) , и "housekeeping" с delete where in -  что ведет к интересным последствиям для постргезовой уродливой системы хранения, с ее "vacuum ненужен, ненужен, ненужнен!"  )
А фэйловерили они ее побайтовым копированием, ага.
Не завидую пришедшему ему на смену.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

16. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" –6 +/–

Сообщение от Ilya Indigo (ok), 10-Май-19, 12:49

> почему столько веток у него?
Разрабам не лень их поддерживать, а может их спонсируют организации использующие сабж.
> какие преимущества и в чем существенные отличия от MySQL/MariaDB?
Отличий множество! Это инструменты для разных целей!
Для WEB-разработки (Как правило подобные вопросы интересуют в основном их, да и сам я интересовался для этого) ничем не лучше - только хуже!
Связка MariaDB + redis + Sphinx - уделывает по производительности чистый сабж!
А если СУБД используется по локалхосту через сокет единственным пользователем (стандартный сценарий WEB-приложений), то MariaDB и быстрее и функциональнее, благодаря возможности использовать разные движки (InnoDB и ROCKSDB) под разные задачи.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

25. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +2 +/–

Сообщение от Catwoolfii (ok), 10-Май-19, 21:14

В 12-й релиз запилили API для новых типов storage engine, новые сторажи завезут скорее всего не раньше 13-го релиза (т.е. минимум года через 1.5).

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

31. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Ilya Indigo (ok), 11-Май-19, 00:59

> В 12-й релиз запилили API для новых типов storage engine, новые сторажи
> завезут скорее всего не раньше 13-го релиза (т.е. минимум года через
> 1.5).
То есть ещё очень не скоро и ещё не известно как эти новые типы себя поведут и сколько времени нужно на их отладку!

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

27. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" –1 +/–

Сообщение от KonstantinB (ok), 11-Май-19, 00:36

> ничем не лучше - только хуже!
Тю.
Вот у меня есть таблица users, в которой есть email и поле deleted_at, которое не null, если пользователь удален.
Я хочу сделать unique index на email, но только для тех юзеров, которые не удалены.
В постгресе я делаю индекс на email where deleted_at is null.
А как в мыскле? Да, есть костыль с persistent virtual column и индексом на него, но - в каком синтаксисе, MariaDB или Oracle mysql?
Или, скажем, у меня есть timestamp и я хочу сделать индекс только по году и месяцу и только для тех записей, где стоит определенный статус.
Или, скажем, я хочу сделать PRIMARY KEY uuid. Как, binary(16) и поворачиваем байтики? Очень удобно.
Или, скажем, у меня есть таблица со структурой, где большинство полей null, и я хочу эффективно искать по любой их комбинации. Или JSON, по внутрянке которого я хочу искать так же эффективно. В постгресе у меня есть GIN и GIST на выбор. В мыскле... мммм... ну, я могу формировать для каждого поля псевдо-слово типа _FIELD_A_IS_123_ и искать фуллтекстом, лол.
Да можно долго перечислять.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

30. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" –1 +/–

Сообщение от Ilya Indigo (ok), 11-Май-19, 00:57

>> ничем не лучше - только хуже!
> Тю.
> Вот у меня есть таблица users, в которой есть email и поле
> deleted_at, которое не null, если пользователь удален.
> Я хочу сделать unique index на email, но только для тех юзеров,
> которые не удалены.
> В постгресе я делаю индекс на email where deleted_at is null.
> А как в мыскле? Да, есть костыль с persistent virtual column и
> индексом на него, но - в каком синтаксисе, MariaDB или Oracle
> mysql?
Текстовые поля вообще не нужно индексировать без крайней на то необходимости, даже для уникальности.
В вашем примере будет просто каша из многих не уникальных email.
В любом случае, нужно сообщить пользователю, что email-занят, так что проверять уникальеность Нужно вручную и индекс UNIQUE тут не нужен!
> Или, скажем, у меня есть timestamp и я хочу сделать индекс только
> по году и месяцу и только для тех записей, где стоит
> определенный статус.
И что мешает индекс на timestamp и статус указать?
> Или, скажем, я хочу сделать PRIMARY KEY uuid. Как, binary(16) и поворачиваем
> байтики? Очень удобно.
Ни понял ни что это ни в чём удобство. Примери у меня всегда только числа!
> Или, скажем, у меня есть таблица со структурой, где большинство полей null,
> и я хочу эффективно искать по любой их комбинации. Или JSON,
> по внутрянке которого я хочу искать так же эффективно. В постгресе
> у меня есть GIN и GIST на выбор. В мыскле... мммм...
Снова не понял в чём тут проблема искать нулы?
> ну, я могу формировать для каждого поля псевдо-слово типа _FIELD_A_IS_123_ и
> искать фуллтекстом, лол.
И снова не понял зачем это нужно и что это даёт?
Если нужен полнотекстовый поиск, то сфинксом сабж по производительности и рядом не стоял!
> Да можно долго перечислять.
Нет, Ваших высранных из пальцев примеров мне больше не нужно.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

36. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +1 +/–

Сообщение от KonstantinB (ok), 11-Май-19, 11:38

Ууууу...
Скажите, а где вы работаете?
Ну так, чтобы случайно туда не обратиться.

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

32. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от GentooBoy (ok), 11-Май-19, 02:08

Единственное в чем выигрывает  Mysql  и его подобия это простота администрирования. В PostgreSQL при помощи обилия ручек вы можете подогнать под свой  workload. По итогу в тех проектах где админ говорит ну оно вот так работает, проще выбрать  mysql, там где нет возможности впендюривать костыли и настраивать БД под задачу проще выбрать  mysql, где программисты хотят просто хранить данные проще выбрать mysql  и сказать ну вот оно так работает. Если вы инженер то должны понимать что забивать гвозди чугунной сковородкой гораздо удобнее чем микроскопом, но это не значит что микроскоп гавно. Просто вы используете его не по назначению.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

37. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Ilya Indigo (ok), 11-Май-19, 12:07

> Единственное в чем выигрывает  Mysql  и его подобия это простота
> администрирования. В PostgreSQL при помощи обилия ручек вы можете подогнать под
> свой  workload. По итогу в тех проектах где админ говорит
> ну оно вот так работает, проще выбрать  mysql, там где
> нет возможности впендюривать костыли и настраивать БД под задачу проще выбрать
>  mysql, где программисты хотят просто хранить данные проще выбрать mysql
>  и сказать ну вот оно так работает. Если вы инженер
> то должны понимать что забивать гвозди чугунной сковородкой гораздо удобнее чем
> микроскопом, но это не значит что микроскоп гавно. Просто вы используете
> его не по назначению.
MySQL также можно подогнать под нужды и настроить там что угодно, хоть кэш отключить, хоть дать подсказки оптимизатору запросов, хоть свой движок написать. Но Вы считаете, что каждый пользователь сабжа занимается его тонкой настройкой?
Впендюривание костылей, да ещё и на этапе разработки, когда не понятен характер нагрузки...
Нет уж, нормальный, в моём понимании, программист на такое не пойдёт!
Это сабж, со своим вакуумом, "вот так работает", которому программную реапликацию совсем недавно завезли. Судя по вашим упоминаниям костылей, самостоятельно она нормально и не работает.
В MySQL можно выбрать и движок, под конкрерную задачу, и тонко настроить выделение памяти, и просто надёжную настроить репликацию (master-slave) и управлять ей. При этом координально изменить работу СУБД Вы всё равно не можете и для максимальной эффективности, Вы должны понимать как она работает в том числе и как работает PostgreSQL!
Я не говорил что сабж какащка. Я говорил что он и MariaDB созданы для разных целей, и для вэб-приложений, где единственный пользователь через сокет и не нужны вообще хранимые процедуры, и есть возможность применить MariaDB+Redis+Sphinx сабж будет хуже, как по быстродействию, так и по надёжности, так и по сложности проектирования и сопровождения.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

40. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от KonstantinB (ok), 11-Май-19, 14:37

Простота администрирования - в базовых случаях да. А тонкий тюнинг innodb - это отдельная уличная магия.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

54. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от нах (?), 14-Май-19, 13:35

если тебе понадобился тонкий тюнинг innodb - посгрез на этом же железе на той же задаче уже давно бы лопнул или необратимо бы крэшнул базу.
Во всяком случае, если решать ее в лоб,  игнорируя оптимизатор-планировщик и особенности хранения. Чего, понятное дело, ни один разработчик не любит, поскольку вся эта оптимизация для того и придумана, чтобы не заморачиваться особенностями конкретной субд.

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

52. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" –1 +/–

Сообщение от нах (?), 14-Май-19, 13:27

> В PostgreSQL при помощи обилия ручек вы можете
кое-как добиться почти такой же производительности и надежности, как у mysql из коробки - если повезет с workload.
Поправил, не благодари.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

57. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Аноним (57), 15-Май-19, 06:19

> ... и надежности, как у mysql
Это в смысле когда база мыскля вдруг тупо впадает в задумчивость и оживает только после прохода
mysqlcheck -r -f ?

Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

17. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от киця (?), 10-Май-19, 13:42

>какие преимущества и в чем существенные отличия от MySQL/MariaDB?
Классика же, ну: https://grimoire.ca/mysql/choose-something-else

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

21. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Аноне (?), 10-Май-19, 19:43

> почему столько веток у него?
потому что более энтерпрайзен, это как Oracle 11, 12, 2018...

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" –1 +/–

Сообщение от Аноним (4), 10-Май-19, 00:41

10й postgres уже готов для продакшена, порекомендовать можете ?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +1 +/–

Сообщение от Аноним (14), 10-Май-19, 09:55

Юзаем 11, проблем особых не испытываем.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

55. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +1 +/–

Сообщение от ОЛЕГ (?), 14-Май-19, 22:02

Тоже 11 в проде

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" –1 +/–

Сообщение от rshadow (ok), 10-Май-19, 10:29

10-й в яндексе используют
https://cloud.yandex.ru/docs/managed-postgresql/qa/postgresql
в гугле 9.6 и 11.1
https://cloud.google.com/sql/docs/postgres/db-versions

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

29. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от KonstantinB (ok), 11-Май-19, 00:41

Давно готов. Уже и на 11-м полет нормальный.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

5. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" –3 +/–

Сообщение от Аноним (4), 10-Май-19, 00:49

И cтоит ли ради всех фич логической репликации апдейтиться с 9.6 до 10.8 ?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +6 +/–

Сообщение от Капитан Очевидность (?), 10-Май-19, 02:50

Если эти фичи вам нужны, то стоит. Если не нужны - то не стоит.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

12. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" –1 +/–

Сообщение от Аноним (10), 10-Май-19, 08:12

Если все устраивает на текущей ветке, то смысле дергаться до осень 21-го года нет никакого.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

56. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" –1 +/–

Сообщение от ОЛЕГ (?), 14-Май-19, 22:03

Ради параллельных вычислений на 11 стоит

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

18. "Обновление PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Аноним (18), 10-Май-19, 15:13

Где-то плачет один Аноним755...

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "Обновление PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" –2 +/–

Сообщение от Аноне (?), 10-Май-19, 19:48

Ребят, а какие линуксовые среды разработки есть годные под него типа [PL]SQL Developer на Оракле?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

35. "Обновление PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Аноним (35), 11-Май-19, 10:12

vim, emacs

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

38. "Обновление PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Аноним (38), 11-Май-19, 13:14

ed жеж, почти edge

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

39. "Обновление PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Аноне (?), 11-Май-19, 13:40

В общем, загуглил, но хотел узнать чем здешние люди пользуются для разработки на PL.

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

43. "Обновление PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +/–

Сообщение от Аноним (14), 11-Май-19, 22:23

> но хотел узнать чем здешние люди пользуются для разработки на PL.
- А чем вы гладите тонкое женское белье?
- ??? ... А чем ВЫ гладите тонкое женское белье?
- Я глажу тонкое женское белье рукой...

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

45. "Обновление PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22" +1 +/–

Сообщение от KonstantinB (ok), 12-Май-19, 06:14

Насчет оркела не знаю, но и для постгреса, и для мыскля мне более чем хватает database-плагина в IntelliJ IDEA. Оно есть и в виде отдельного продукта, DataGrip называется, попробуйте, может, там и с Ораклом все хорошо. Поддержка по крайней мере заявлена.
Да это все, конечно, проприетарщина, но раз у вас Оракл, думаю, не должно смущать.

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	–1 +/–
Сообщение от Аноним (1), 09-Май-19, 23:28
Объясните мне, почему столько веток у него? А также вопрос к тем, кто давно юзает и разбирается, какие преимущества и в чем существенные отличия от MySQL/MariaDB? Благодарю заранее.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	3. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	–11 +/–
	Сообщение от хотел спросить (?), 10-Май-19, 00:34
	Посмотрите темку в нете почему Uber ушел с постгреса на мускл. А вообще подбешивают таблицы большими буквами и т.д. В посгресе дофига плагинов. Есть говновакуум.. в общем пока не попробуешь под свои задачи - непонтяно, что лучше он или MySQL. Я за последний.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	19. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от Аноним (19), 10-Май-19, 18:02
	Тащем-то в мыскле тоже наличествует свой вакуум, который время от времени тоже надо применять на движках сложнее MyISA.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	23. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от Онаним (?), 10-Май-19, 20:35
	Штэ?
	Ответить \| Правка \| ^ к родителю #19 \| Наверх \| Cообщить модератору


	34. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+3 +/–
	Сообщение от Аноним (19), 11-Май-19, 04:59
	OPTIMIZE TABLE table_name; Не знал? Фанбои мыскля еще много чего про свой фетиш не знают. И прямую ложь про "нет вакуума" двадцать лет всем в уши дуют.
	Ответить \| Правка \| ^ к родителю #23 \| Наверх \| Cообщить модератору


	26. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от zekefast (ok), 11-Май-19, 00:15
	Какой ещё MyISAM? Все давно используют InnoDB. А для тех кто всё же поленился пройти по указанным материалам от Uber-a и смежным докладам, даже русскоязычных докладчиков... У InnoDB табличный движок более хорошо приспособлен для определённых типов операций и постоен на UNDO таблице в которую помещаются данные колонок обновлённых записей на которые ещё есть открытые транзакции. Как следствие этого при закрытии транзакций и репликации данные можно просто удолить из этой специальной таблицы без порождения фрагментации данных в таблице на диске. Движок PostgreSQL копирует обновлённую запись, а старую помечает, как удалённую. Новые транзакции пускаются на новую запись, а старая завершает обслуживание уже начатых транзакций. Как следствие, старые записи надо вычищать для чего и служит механизм VACUUM. Но при больших нагрузках и частых записях возникает проблема, так как процесс VACUUM более ресурсоёмкий чем чистка отдельной таблицы UNDO. Так же как следствие подобной организации работы с данными является разница в качестве работы репликации в этих базах и по сути невозможность master-master репликации для PostgreSQL. Если в 11 версии ничего не поменялось. Не смотрел её ещё. In a nutshell...
	Ответить \| Правка \| ^ к родителю #19 \| Наверх \| Cообщить модератору


	41. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от Дима (??), 11-Май-19, 17:35
	Спасибо посмеялся. InnoDB сразу данные удаляет? Только недавно делал на базе с ним чистку, так после OPTIMIZE TABLE база похудела на 50 гиг. Причём делался он ну очень, очень долго.
	Ответить \| Правка \| ^ к родителю #26 \| Наверх \| Cообщить модератору


	44. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от zekefast (ok), 12-Май-19, 00:47
	> Спасибо посмеялся. InnoDB сразу данные удаляет? Только недавно делал на базе с > ним чистку, так после OPTIMIZE TABLE база похудела на 50 гиг. > Причём делался он ну очень, очень долго. Я не говорил о моментальном удалении данных. Я говорил о том, что механизм UNDO более дешёвый с точки зрения производительности чем механизм VACUUM при котором надо сканить таблицы и что-то делать с фрагментацией данных.
	Ответить \| Правка \| ^ к родителю #41 \| Наверх \| Cообщить модератору


	46. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от DeadMustdie2 (?), 12-Май-19, 11:19
	> механизм UNDO более дешёвый с точки зрения производительности чем механизм VACUUM Сильно зависит от нагрузок. UNDO в стиле Oracle, грубо говоря, удваивает объем выполняемой записи в журнал - потому что его надо тоже защищать REDO.
	Ответить \| Правка \| ^ к родителю #44 \| Наверх \| Cообщить модератору


	48. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от КО (?), 13-Май-19, 10:34
	>Oracle, грубо говоря, удваивает объем выполняемой записи в журнал Ну если грубо говоря, то учетверяет. Пишем журнал->undo->журнал->обновленную запись. В PG 3 : журнал->новая->пометка старой У Oracle выигрыш в использовании места (а соответственно быстрее full scan) на частых update, но и chained rows как следствие.
	Ответить \| Правка \| ^ к родителю #46 \| Наверх \| Cообщить модератору


	49. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от Andrey Mitrofanov (?), 13-Май-19, 10:57
	> В PG 3 : журнал->новая->пометка старой О! Капитан, уточните, какие из трёх указанных "running service" (или как бы это назвать -- запущенный сервис с кешом (("мастер", реплики вообще не интересны--)) в озу) таки-да _не_ пишет на диск _вне чекпоинтов_. Мне всегда это было интересно, но всё никак не могу разобраться до конца. Есть "оптимистичное" предположение, что не пишутся при указанных условиях 2 из 3-ёх. Но есть смутные сомнения, что условия не все или не те... Требуется помощь очевидных войск... ?
	Ответить \| Правка \| ^ к родителю #48 \| Наверх \| Cообщить модератору


	58. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от КО (?), 18-Май-19, 09:36
	> Есть "оптимистичное" предположение, Да. Оптимистично только журнал. Но это при условии что нагрузка нерегулярная и иногда дает покурить. А если постоянная и на максимуме, как в свое время в Сбере, то в какой-то момент времени выясняется, что терабайт памяти пишется на диск не моментально, а если запаниковать, то его еще из журналов восстанавливать надо, что тоже не ускоряет процесс.
	Ответить \| Правка \| ^ к родителю #49 \| Наверх \| Cообщить модератору


	50. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+1 +/–
	Сообщение от DeadMustdie2 (?), 13-Май-19, 11:08
	>>Oracle, грубо говоря, удваивает объем выполняемой записи в журнал > Ну если грубо говоря, то учетверяет. Пишем журнал->undo->журнал->обновленную запись. Удваивает запись в журнал - т.е. синхронную запись, которая напрямую влияет на скорость выполнения. Вся остальная запись асинхронная, и влияние её косвенное (увеличивает количество IOPS, но при этом хорошо параллелится и не блокирует дальнейшие действия приложения). > В PG 3 : журнал->новая->пометка старой > У Oracle выигрыш в использовании места (а соответственно быстрее full scan) > на частых update, но и chained rows как следствие. Алгоритмы Oracle сокращают фрагментацию основного табличного пространства ценой двойной фиксации изменений: в основное табличное пространство и в UNDO.
	Ответить \| Правка \| ^ к родителю #48 \| Наверх \| Cообщить модератору


	47. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от Аноним (19), 12-Май-19, 16:52
	Тут такое дело, VACUUM в PG дело добровольное. И если его не дергать, то он ни на что не влияет. И получается так, что у мыскля с его UNDO производительность только съедается впустую. И да, если в мыскле применить аналог vacuum'а, то таблицы лочатся намертво.
	Ответить \| Правка \| ^ к родителю #44 \| Наверх \| Cообщить модератору


	42. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+1 +/–
	Сообщение от Дима (??), 11-Май-19, 17:36
	Причём таблица блокируется полностью
	Ответить \| Правка \| ^ к родителю #26 \| Наверх \| Cообщить модератору


	24. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от Аноним (24), 10-Май-19, 20:35
	>Посмотрите темку в нете почему Uber ушел с постгреса на мускл. Если не просто посмотреть, а ещё и почитать, то можно увидеть, что Uber, фактически, реализует файловую систему поверх SQL, для чего MySQL внезапно подходит значительно лучше именно благодаря своей примитивности.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	6. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	–7 +/–
	Сообщение от Michael Shigorin (ok), 10-Май-19, 02:21
	Так скакать с ветки на ветку не все умеют одинаково хорошо. PS: ушло в репозиторий sisyphus_e2k ещё утром 9 мая.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	9. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	–2 +/–
	Сообщение от Константавр (ok), 10-Май-19, 07:47
	А почему у них должны возникать проблемы? Оно настолько безоглядно разрабатывается, что даже в рамках девятой версии аж три ветки приходится поддерживать? Это базы данных-то? Офигеть.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	10. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+2 +/–
	Сообщение от Аноним (10), 10-Май-19, 08:06
	До 10-й версии мажорными считались релизы 9.x минорными 9.x.y, как уже сказали, между мажорными версиями нет бинарной совместимости файлов, и весьма разный набор фич. Начиная с 10-й версии схему привели к общепринятому виду, убрав лишнюю цифру из версии.
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	20. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от Аноним (20), 10-Май-19, 19:03
	Непонятно что вас смущает в LTS, это же стандартная практика для серьёзного софта.
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	8. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от Аноним (8), 10-Май-19, 02:53
	Потому что это секьюрити-фиксы. И потому что в постгресе нет бинарной совместимости между разными мажорными версиями.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	11. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+3 +/–
	Сообщение от Аноним (10), 10-Май-19, 08:11
	Его главное отличие от MariaDB, MySQL, Percona - он один. Все чаще наблюдаю картину, когда компоненты работающие в рамках одного проекта ранее спокойно жили вместе на одной БД на мыскле, теперь могут начинать конфликтовать из-за того, что кто-то хочет фичи от MariaDB а кому-то подавай ортодоксальный MySQL от оракакеля. И чем дальше, тем разломы между фактически одной и той же СУБД только расширяются и углубляются. Что тут скажешь, фанбои мыскля сами выбрали свой путь страдания.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	28. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от KonstantinB (ok), 11-Май-19, 00:39
	Мне кажется, что Оракл специально реализует фичи из MariaDB с другим синтаксисом, чтобы усложнить миграцию.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	33. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от Аноним (19), 11-Май-19, 04:54
	Да это как-то однопенисно. Вот то, что они уже пилят две разные несовместимые клиентские библиотеки, вот это п....ц и Израиль.
	Ответить \| Правка \| ^ к родителю #28 \| Наверх \| Cообщить модератору


	51. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от нах (?), 14-Май-19, 13:26
	ну так он вызван изначальной глупостью - пытаться вместо чистого форка сделать drop-in replacement. В результате совместимость все равно поломана, но вот удержать на одном хосте две разные - теперь неприемлемый геморрой (слава виртуалочкам, что уже низачем и не нужно)
	Ответить \| Правка \| ^ к родителю #33 \| Наверх \| Cообщить модератору


	14. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от Аноним (14), 10-Май-19, 10:01
	> какие преимущества и в чем существенные отличия от MySQL/MariaDB? В рамках данной дискуссии ваш вопрос относится скорее к категории религиозных. Преимущества и недостатки имеют все перечисленные системы. Для админа локалхоста/конторы до 1000 юзеров вообще никакой разницы, кроме той, что MySQL везде, где заявлена/требуется БД всунут по умолчанию, а для использования вместо него PostgreSQL придется приложить некие минимальные дополнительные усилия.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	53. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от нах (?), 14-Май-19, 13:32
	бросьте, вот только что приходил товарисч, взгромоздивший на постгрез zabbix. В конторе до 1000 и никто его не заставлял. (ну да, ну да - с его бесконечными поштучными insert, запросами where ... in ( ) , и "housekeeping" с delete where in - что ведет к интересным последствиям для постргезовой уродливой системы хранения, с ее "vacuum ненужен, ненужен, ненужнен!" ) А фэйловерили они ее побайтовым копированием, ага. Не завидую пришедшему ему на смену.
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	16. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	–6 +/–
	Сообщение от Ilya Indigo (ok), 10-Май-19, 12:49
	> почему столько веток у него? Разрабам не лень их поддерживать, а может их спонсируют организации использующие сабж. > какие преимущества и в чем существенные отличия от MySQL/MariaDB? Отличий множество! Это инструменты для разных целей! Для WEB-разработки (Как правило подобные вопросы интересуют в основном их, да и сам я интересовался для этого) ничем не лучше - только хуже! Связка MariaDB + redis + Sphinx - уделывает по производительности чистый сабж! А если СУБД используется по локалхосту через сокет единственным пользователем (стандартный сценарий WEB-приложений), то MariaDB и быстрее и функциональнее, благодаря возможности использовать разные движки (InnoDB и ROCKSDB) под разные задачи.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	25. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+2 +/–
	Сообщение от Catwoolfii (ok), 10-Май-19, 21:14
	В 12-й релиз запилили API для новых типов storage engine, новые сторажи завезут скорее всего не раньше 13-го релиза (т.е. минимум года через 1.5).
	Ответить \| Правка \| ^ к родителю #16 \| Наверх \| Cообщить модератору


	31. "Обновлнение PostgreSQL 11.3, 10.8, 9.6.13, 9.5.17 и 9.4.22"	+/–
	Сообщение от Ilya Indigo (ok), 11-Май-19, 00:59
	> В 12-й релиз запилили API для новых типов storage engine, новые сторажи > завезут скорее всего не раньше 13-го релиза (т.е. минимум года через > 1.5). То есть ещё очень не скоро и ещё не известно как эти новые типы себя поведут и сколько времени нужно на их отладку!
	Ответить \| Правка \| ^ к родителю #25 \| Наверх \| Cообщить модератору