The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]



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

"Релиз СУБД PostgreSQL 11"  +/
Сообщение от opennews (?), 19-Окт-18, 13:59 
После года разработки опубликована (https://www.postgresql.org/about/news/1894/) новая стабильная ветка СУБД PostgreSQL 11.  Обновления для новой ветки будут выходить (http://www.postgresql.org/support/versioning/) в течение пяти лет до октября 2023 года. Основное внимание при подготовке новой ветки было уделено расширению функциональности в областях управления очень большими базами данных и  разработки приложений для масштабируемой обработки больших данных.


Основные новшества (https://www.postgresql.org/docs/11/static/release-11.html):


-  Добавлена возможность применения JIT-компиляции (Just-in-Time) для ускорения выполнения некоторых выражений  в процессе обработки SQL-запроса. Например, JIT применим для ускорения выполнения выражений внутри блоков "WHERE", в выходных списках (target lists), агрегатных выражениях и  проекциях. JIT также задействован для ускорения некоторых внутренних операций. Предложенный JIT-компилятор построен на основе наработок LLVM  и для включения требует установки дополнительных зависимостей, связанных с LLVM. Включение осуществляется настройкой "jit = on" в файле конфигурации или командой "SET jit = on" в интерактивном сеансе;

-  Добавлен новый вид хранимых процедур, позволяющих использовать транзакции. Процедуры определяются с  использованием синтаксиса SQL и позволяют использовать все средства управления транзакциями. Поддержка транзакций даёт возможность создавать более продвинутые серверные обработчики, например, для пакетной загрузки данных. Для определения хранимых процедур с транзакциями добавлена новая команда CREATE PROCEDURE (https://www.postgresql.org/docs/11/static/sql-createprocedur...). Для выполнения процедуры используется команда CALL. К SQL-процедурам  также можно обращаться из хранимых процедур на PL/pgSQL, PL/Perl, PL/Python и PL/Tcl;


-  Улучшения, связанные с секционированием (партицированием):

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

-  Обеспечена корректная маршрутизация операций  INSERT, UPDATE и COPY  для секционированных таблиц, обрабатываемых с использованием модуля postgres_fdw (https://www.postgresql.org/docs/current/static/postgres-fdw....) (логически объединяет таблицы с нескольких серверов);


-  Представлена секция "catch-all", которая используется по умолчанию для  данных, не соответствующих ключу секции, и позволяет применять первичные ключи, внешние ключи, индексы и триггеры над секционированными таблицами.
-  Обеспечен автоматическое перемещение записей в корректную секцию, после изменения в записи ключа для выбора секции;


-  Увеличена производительность запросов при чтении данных из секций;

-  Добавлена возможность применения операции "upsert"  (добавить-или-модифицировать) к секционированным таблицам, что позволяет упростить код приложений и снизить число сетевых запросов;


-  Проведена работа по увеличению производительности параллельной обработки запросов. Увеличена производительность распараллеливания операций последовательного сканирования и слияния хэшей. Добавлена возможности распараллеливания операций при выполнении команд "CREATE TABLE ... AS", "CREATE MATERIALIZED VIEW" и блоков UNION. В команду "CREATE INDEX" добавлена поддержка параллельная обработка данных при построении индексов B-tree;

-  Реализована возможность обойтись без полной перезаписи таблицы при выполнении "ALTER TABLE ... ADD COLUMN" при отличающемся от null  значении столбца по умолчанию;

-  В "CREATE INDEX" добавлена опция INCLUDE для создания индекстов-обёрток, включающих дополнительные столбцы;

-  В оконные функции добавлена поддержка всех опций "рамок окна" (window frame), определённых в стандарте SQL:2011, включая возможность использования RANGE для PRECEDING/FOLLOWING, режима GROUPS и опций исключения рамок;

-  В интерфейс командной строки в дополнение к штатной команде "\q" добавлены более привычные для новичков команды "quit" и "exit".

URL: https://www.postgresql.org/about/news/1894/
Новость: https://www.opennet.ru/opennews/art.shtml?num=49462

Ответить | Правка | Cообщить модератору

Оглавление

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


2. "Релиз СУБД PostgreSQL 11"  –9 +/
Сообщение от Dmrjan (?), 19-Окт-18, 14:02 
Буду ждать PostgreSQL Pro.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

97. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Аноним (97), 20-Окт-18, 13:14 
Я вот не пойму, почему этих ребят за нарушение тм в суд не пригласили?
У них договорённости какие-то или они на территории США не распространяются?
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

137. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от hiveliberty (ok), 22-Окт-18, 10:55 
Да, тоже интересно было.. Но, вот почему, как я понимаю: https://postgrespro.com/about
С официального https://www.postgresql.org/docs/ даже линк на доки на https://postgrespro.com
Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

138. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Andrey Mitrofanov (?), 22-Окт-18, 10:58 
> Я вот не пойму, почему этих ребят за нарушение тм в суд

Какое "нарушение"??  Это-то Вы, надеюсь, понимаете хотя до уровня -- объяснить.  Прошу.

> не пригласили?

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

142. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от KonstantinB (??), 22-Окт-18, 16:30 
Нарушение, простите, чего? BSDL?
Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

144. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Andrey Mitrofanov (?), 22-Окт-18, 16:51 
> Нарушение, простите, чего? BSDL?

"" анОним с нарушенным шаблоном взывает к суду. ""

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

3. "Релиз СУБД PostgreSQL 11"  –5 +/
Сообщение от Ivan (??), 19-Окт-18, 14:06 
Когда движок перепилят, что бы избавится от вакуума?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Ilya Indigo (ok), 19-Окт-18, 14:19 
Хотел тоже спросить.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "Релиз СУБД PostgreSQL 11"  +2 +/
Сообщение от Dmrjan (?), 19-Окт-18, 14:22 
> Когда движок перепилят, что бы избавится от вакуума?

Зачем его выпиливать. Это крайне нужна вещь. Вакуум конечно можно отключить, но так вы базы загубите.

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

13. "Релиз СУБД PostgreSQL 11"  +2 +/
Сообщение от Ilya Indigo (ok), 19-Окт-18, 15:09 
Вы говорите про следствие (вакум), а автор спросил про причину (движок).
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

17. "Релиз СУБД PostgreSQL 11"  –3 +/
Сообщение от Аноним (17), 19-Окт-18, 15:44 
С текущим движком постгри всё так. О том и речь, чтобы сделать наконец нормальный движок как в приличных СУБД.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

27. "Релиз СУБД PostgreSQL 11"  +3 +/
Сообщение от Аноним (27), 19-Окт-18, 16:49 
А "Нормальные" это какие?
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

67. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от _dz (?), 19-Окт-18, 21:32 
Ну, Оракл, видимо.
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

79. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Аноним (79), 19-Окт-18, 23:09 
Это который ORA-01555; Snapshot too old? Нет, такой движок нам не нужен :-)
Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

85. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Мудила (?), 19-Окт-18, 23:42 
Ну ведь это тоже чисто "проблема реализации". Сделайте Сегмент отката пожирнее.
Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

133. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от anonymous (??), 21-Окт-18, 20:39 
Нет это не "сегементы отката пожирнее". Если бы так то была бы ошибка о нехватки места в undo.

А эта ошибка - проблема глупой (женской?) логики,
когда сначала "нет мне эти данные больше не нужны",
а через некоторое время "а дай мне те данные которые я говорила, что не нужны".

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

134. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Мудила (?), 21-Окт-18, 23:09 
Конкретней?
Это ошибка, связанная с тем, что данные были из Сегмента отката вытеснены по причине их устаревания. Вот и всё. Больше Сегмент отката -- больше данных предыстории можно в них запихнуть, более длинные транзакции можно делать. Вот и всё. Нет тут никакой эзотерики или "женской" логики.
Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

96. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от 123456789 (??), 20-Окт-18, 12:54 
ORA-600 же
Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

68. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (68), 19-Окт-18, 21:36 
> А "Нормальные" это какие?

Поколоночные? Типа Apache Kudu? Они точно нормальны к строкам....

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

12. "Релиз СУБД PostgreSQL 11"  +3 +/
Сообщение от Andrey Mitrofanov (?), 19-Окт-18, 15:02 
> Когда движок перепилят, что бы избавится от вакуума?

Как только из SQLя выкинут консистентность данных, транзакционность и пр. совершенно ненужные атавизмы.

Пишите письмя в ANSI и ISO!
  https://en.wikipedia.org/wiki/Multiversion_concurrency_control
  https://en.wikipedia.org/wiki/SQL#Interoperability_and_stand...

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

14. "Релиз СУБД PostgreSQL 11"  –3 +/
Сообщение от Ilya Indigo (ok), 19-Окт-18, 15:11 
И как только InnoDB без всяких вакуумов справляется, предоставляя транзакционность и прочее нужное?
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

18. "Релиз СУБД PostgreSQL 11"  +8 +/
Сообщение от morruth (?), 19-Окт-18, 15:53 
вы таки будете смеяться, но вакуум там есть, просто называется по другому
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

20. "Релиз СУБД PostgreSQL 11"  +5 +/
Сообщение от ajp (?), 19-Окт-18, 15:56 
И только почему-то в InnoDB нужно периодически запускать optimize.
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

31. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 19-Окт-18, 16:55 
Ильюша, аналог "вакуума" есть во всех mvcc-рсубд. Это основа подхода -- сохранять исторические данные для организации многоверсионности. Реализаций существует несколько -- ни одна из них не являет особых преимуществ перед другими.
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

41. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Ilya Indigo (ok), 19-Окт-18, 17:46 
Совсем не лучше?
https://habr.com/company/southbridge/blog/322624
Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

44. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Аноним (27), 19-Окт-18, 17:49 
Хабр читать не буду. Хотите что-то узнать попробуйте осмысленно пересказать мне о чём там, я может и отвечу что-нибудь. Хотя не очень понимаю зачем мне этим культпросветом заниматься.
Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

55. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Ilya Indigo (ok), 19-Окт-18, 18:14 
Наиболее важное архитектурное отличие заключается в том, что Postgres напрямую сопоставляет записи индекса с адресами на диске, а в InnoDB есть дополнительная структура, в рамках которой записи индекса содержат не указатель на место на диске (как ctid в Postgres), а указатель на значение первичного ключа. Таким образом, ключи вторичных индексов в MySQL ассоциированы со значениями первичного ключа:
Чтобы выполнить поиск по индексу (first, last), необходимо выполнить два действия: найти первичный ключ записи в таблице, а затем в индексе по первичному ключу отыскать расположение строки на диске.

Такое конструктивное решение ставит InnoDB в менее выгодное положение по сравнению с Postgres, поскольку предполагает выполнение дополнительной операции по поиску ключа. Однако, так как данные нормализованы, при обновлении строк затрагиваются только те индексы, которые построены по изменившимся полям. Также InnoDB обычно выполняет обновления строк прямо на месте. Если каким-либо транзакциям в рамках механизма MVCC необходима старая версия строки, MySQL копирует ее в специальную область под названием сегмент отката (rollback segment).

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

57. "Релиз СУБД PostgreSQL 11"  +2 +/
Сообщение от Аноним (27), 19-Окт-18, 18:17 
Замечательно, что вы освоили ctrl-c и ctrl-v, но что из этого вы поняли? Вы критически можете оценить, что тут написано? Без иронии всякой спрашиваю.
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

58. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 19-Окт-18, 18:29 
Объясню. В Оракле записи в Сегмент отката обслуживается "на общих основаниях", т.е. сначала идёт запись в журнал повторного исполнения, только после этого происходит запись в Сегмент отката. Поэтому в случае краха данные утрачены не будут. В Инно это не так -- в Инно запись в Сегмент отката не защищается журналом транзакций. Это делает процедуру быстрее: меньше операций записи в разные места -- быстрее операция. Но делает такую операцию опасной. Это не говоря о том, что запись в Сегмент отката (в случае Инно, в Оракле -- не так реализовано) это копирование данных, т.е. считывание и запись, что никак не может быть быстрее "замогиливания" и вставки в Слоне...
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

60. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Аноним (27), 19-Окт-18, 18:41 
У Инно ещё и косяки с синхронизацией. Нужно быть отчаянным авантюристом, чтобы Инно использовать для надёжной обработки коммерчески значимых данных.
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

86. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Ага (?), 20-Окт-18, 01:20 
Достаточно провести нагрузочное тестирование перед вводом в прод ну и не пользоваться оптимистичными блокировками при многопоточной репликации
Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

62. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 19-Окт-18, 18:59 
Сама по себе концепция кластерного индекса не делает Инно не хуже, не лучше, чем Слон, в котором кластерных "таблиц" нет. Это вообще ничего о производительности не говорит.
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

46. "Релиз СУБД PostgreSQL 11"  +2 +/
Сообщение от Аноним (27), 19-Окт-18, 17:53 
ААААааааа.... Чуваки из Убера на полном серьёзе пишут, что транзакционность это ненужное фуфло, потому... что замедляет запись )))))))) Вот новость-то.
Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

69. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (69), 19-Окт-18, 21:59 
Да и флаг им в руки.
Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

100. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (100), 20-Окт-18, 13:51 
А ты свои 10 записей пишешь и тебе хватает. Как поработаешь с нагруженными прилржениями, поймешь, что это такое и какая нужна производительность
Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

113. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Анонимно (?), 20-Окт-18, 15:39 
Ты, наверное админ, который про базы только в школе слышал и наверное тебе не рассказали что консистентность можно поддерживать разными способами
Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

45. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Аномномномнимус (?), 19-Окт-18, 17:52 
Тоже расскажи, а то посмотришь на хард после OPTIMIZE TABLE и прям диву даёшься
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

54. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 19-Окт-18, 18:14 
Ещё раз. Это общая проблема. Никто её пока как-то сильно лучше других не решил. Статистику нужно обновлять, индексы обновлять, данные отмены где-то и как-то хранить, а потом очищать. У всех одинаковые проблемы.
Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

109. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (109), 20-Окт-18, 15:27 
InnoDB на SSD или при преимущественно рандомных выборках не-range на любом носителе OPTIMIZE TABLE наксер не нужен, поскольку фрагментация роли не играет. Повторное использование страниц при этом есть.

Для write-mostly нагрузок есть TokuDB, у которого реюз также сделан.

У постгри же вакуум в этих случаях также не отменяется, а для write-mostly вообще нет ничего.

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

15. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от пох (?), 19-Окт-18, 15:14 
да, я тоже что-то не понял, где в списке новостей - "1. vacuum deprecated и назначен к выпиливанию в 11.1" - сопровождавшее все выпуски, кажется, начиная с 8. Наверное, автор новости просто невнимательно читал оригинал. ;-)


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

112. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (109), 20-Окт-18, 15:31 
В пользу автовакуума, угу, который один ксер тот же вакуум. Как вы с этим кактусом живёте. Ну ладно на хдд фрагментирование допустим таблиц InnoDB требовало аккуратного подхода, но вот на SSD-то оно не актуально уже.
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

116. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от пох (?), 20-Окт-18, 18:45 
вы свое "фрагментирование" (которое многозадачной системе, вообще-то, изрядно до лампы) с бесконечным разрастанием таблиц и их индексов из-за банального update -то не путайте.

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

16. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Catwoolfii (ok), 19-Окт-18, 15:35 
Когда EnterpriseDB допилит zheap и протолкнет его в ваниль, тогда и будет...
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

33. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 19-Окт-18, 17:18 
А зачем? Чем "вакуум"-то мешает жить тем, кому он... мешает жить? Чем Сегменты откаты в Оракле удобней? Обычно про вакуум визжат ничего сложней Дельфина никогда не пробовавшие.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

73. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от пох (?), 19-Окт-18, 22:25 
> Чем "вакуум"-то мешает жить

тем что жрет ресурсы как не в себя и при этом не работает. И в результате - vacuum full; reindex

> Чем Сегменты откаты в Оракле удобней?

тем что они вне стора и после завершения транзакции просто помечаются как ненужные.

обычно проблема ваккума непонятна "аналитикам", которые никогда в базе ничего не меняют.

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

80. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (79), 19-Окт-18, 23:14 
> тем что жрет ресурсы как не в себя

это настраивается

> и при этом не работает.

у всех работает

> И в результате - vacuum full

vacuum full не нужен

> reindex

тут не спорю, нужен, но маловероятно что отказ от вакуума это исправит, индексы всё равно будут пухнуть из-за поддержки многопоточности, либо придётся сильнее лочиться

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

98. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (98), 20-Окт-18, 13:27 
> у всех работает

Отучаемся говорить за всю сеть.

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

107. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Catwoolfii (ok), 20-Окт-18, 15:07 
Ну вообще то он работает, просто файлы остаются "разряженные"
Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

128. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Мудила (?), 21-Окт-18, 14:19 
Т. е. по вашему получается, что обслуживание Сегментов отката даром даётся ))) Ну, оно как-то само там что-то с собой делает. И хватит тут кичится своим невежеством и непрофессионализмом. Если у вас что-то не получается, то слушайте тех, у кого получается, а не хамите, как пэтэушник. "Проблема вакуума" непонятна тем, кто по этой проблеме и пары страниц не удосужился прочитать, но рассказывает тут какой он "практик". Даже не смешно уже.
Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

150. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от пох (?), 22-Окт-18, 21:45 
ну, скажем так - оно во-первых вполне предсказуемое, во вторых, в самом банальном варианте таки даром, да - напоминаю, что постгрез раздувает и стор и индекс на банальном update не-ключевых полей. Без всяких параллельных транзакций и длительных блокировок - просто потому что вот так он у него устроен. В этом он совершенно уникален, кто-то там своего PhD в 95м за эту фичу получил.

> И хватит тут кичится своим невежеством и непрофессионализмом.

переадресую вам этот полезный совет.

> Если у вас что-то не получается, то слушайте тех, у кого получается

мамкиных dba, не понявших даже в чем, собственно, проблема, потому что на их append-only базе такого вообще не бывает? Спасибо, неинтересно мне вас слушать. "пару страниц прочитавших", ага.

"такая же нога, и не болит".

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

28. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 19-Окт-18, 16:50 
Это уже очень давно произошло.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

35. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Аноним (27), 19-Окт-18, 17:19 
Иван, а что вы знаете о СУБД вообще? Хоть что-нибудь знаете, а? Ну хоть чуть-чуть?
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

43. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (43), 19-Окт-18, 17:49 
Другой вопрос, когда появится поддержка других хранилищь, помимо блочных устройств? Энергонезависимую память уже втыкают в слот оперативной. MySQL уже несколько десятков лет умеет работать с оперативкой.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

51. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Аноним (27), 19-Окт-18, 18:07 
А как понять "умеет работать с оперативкой"? Все современные СУБД "умеют работать с оперативкой", с ней только и работают.
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

78. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (78), 19-Окт-18, 22:44 
А что, оперативка и NVME вдруг перестали работать как блочные устройства?
Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

115. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (115), 20-Окт-18, 18:24 
т.е. вы предлагаете то, что можно адресовать по-байтно, адресовать по-блочно, чтобы только ничего не переделывать?
Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

118. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Мудила (?), 20-Окт-18, 20:16 
З а ч е м? Объём накладных расходов возрастает в десятки раз. Вы не задумывались почему так распространена постраничная адресация, а? Микроменеджмент всего это хозяйства будет занимать все ресурсы.
Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

8. "Релиз СУБД PostgreSQL 11"  +9 +/
Сообщение от Ононимус (?), 19-Окт-18, 14:27 
В интерфейс командной строки в дополнение к штатной команде "\q" добавлены более привычные для новичков команды "quit" и "exit".

Джва года ждал!

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

11. "Релиз СУБД PostgreSQL 11"  +7 +/
Сообщение от Аноним (11), 19-Окт-18, 15:02 
...пока ждал - привык к \q)))
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

19. "Релиз СУБД PostgreSQL 11"  +11 +/
Сообщение от morruth (?), 19-Окт-18, 15:54 
всегда по ctrl-D выходил :)
Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

21. "Релиз СУБД PostgreSQL 11"  +12 +/
Сообщение от 1 (??), 19-Окт-18, 16:07 
требую добавить :q
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

139. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Анонимусис (?), 22-Окт-18, 11:11 
Ctrl + D Остальное для слабаков
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

9. "Релиз СУБД PostgreSQL 11"  –9 +/
Сообщение от Аноним (9), 19-Окт-18, 14:27 
>Добавлен новый вид хранимых процедур, позволяющих использовать транзакции

Не поклонник слоника, но вот от этого офигел.
Только добавили? Едрить!

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

22. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Аноним (22), 19-Окт-18, 16:19 
Это вложенные транзакции, дурилка.
И это очень круто.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

24. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от абв (?), 19-Окт-18, 16:24 
Из описания новости не понятно ни черта.

Оно: https://wiki.postgresql.org/wiki/Autonomous_subtransactions ?

Или раньше нельзя было сделать BEGIN внутри функции?

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

25. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (22), 19-Окт-18, 16:45 
Во-первых: https://www.postgresql.org/docs/11/static/xproc.html
Во-вторых, в функции можно было, в процедуре - нет
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

50. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от абв (?), 19-Окт-18, 18:00 
> Во-вторых, в функции можно было, в процедуре - нет

Судя по https://www.postgresql.org/docs/11/static/sql-createprocedur... раньше и не было CREATE PROCEDURE.

В целом, я так и не понял разницу между функцией и процедурой (кроме как вы методе вызова и том, что процедура ничего не возвращает).

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

52. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Аноним (27), 19-Окт-18, 18:08 
Значит, никогда ни транзактом, ни с пл-, ни с пг-сиквелом дел не имели. И с СУБД вообще. Зачем тогда вам разбираться в этих тонкостях?
Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

64. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от абв (?), 19-Окт-18, 19:10 
> Зачем тогда вам разбираться в этих тонкостях?

Для развития.

Назад к сути. Где в офф.документации почитать про разницу? Спасибо.

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

71. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Мудила (?), 19-Окт-18, 22:12 
Исторически разница была в том, что функции можно было встраивать в SQL-выражения, т.е. они возвращали recordset, а процедуры -- нет.
Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

72. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Мудила (?), 19-Окт-18, 22:19 
Ну, я несколько не точно выразился. Процедуры тоже можно было в SQL-код встраивать, но они возвращали "скаляр", т.е. конкретное единичное значение. А функции -- могли вернуть и набор строк. Одни можно было использовать исключительно в процедурных расширениях, а другие -- в обычном декларативном коде.
Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

30. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Аноним (27), 19-Окт-18, 16:52 
Не то чтоб очень круто, а "как в Оракле".
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

81. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (79), 19-Окт-18, 23:29 
> Это вложенные транзакции

Нет, наоборот, это возможность вызвать процедуру _вне_ транзакции, что бы транзакцией управляла она сама.

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

110. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Аноним (109), 20-Окт-18, 15:29 
Шёл 2018 год...
Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

10. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Аноним (78), 19-Окт-18, 14:33 
> слияния хэшей

hash join это не "слияния хэшей"

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

23. "Релиз СУБД PostgreSQL 11"  –2 +/
Сообщение от абв (?), 19-Окт-18, 16:20 
> Добавлен новый вид хранимых процедур, позволяющих использовать транзакции.

В оригинале:
> SQL stored procedures that support embedded transactions

Что за "embedded transactions"?
Имеется в виду "autonomous transactions" или что-то другое?

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

26. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Rodegast (ok), 19-Окт-18, 16:47 
Когда выпустят нормальный PgAdmin?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

29. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Аноним (27), 19-Окт-18, 16:51 
А зачем он? Я DBeaver-ом пользуюсь. Для всего. И для Слона тоже. Вполне достаточно.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

48. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Аномномномнимус (?), 19-Окт-18, 17:57 
Оооо!!! Спасибо, похоже это то, что я давно хотел.
А он умеет по SSH и через PHP-прокси в базы данных стучать, как Navicat?
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

53. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 19-Окт-18, 18:11 
Не знаю, не пробовал.
А зачем это вот прям уметь? Туннель сторонними средствами можно ведь без проблем сделать, только порты пробросить.
Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

63. "Релиз СУБД PostgreSQL 11"  –2 +/
Сообщение от Аномномномнимус (?), 19-Окт-18, 19:02 
Не на всех хостингах можно использовать SSH, а так же вертеть mysql как угодно, а в БД бывает надо поковыряться. И в итоге в худших случаях начинается цирк с "забекапить, скачать, развернуть, поправить, сбекапить, залить обратно, развернуть"
Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

66. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от й (?), 19-Окт-18, 21:02 
navicat, на минуточку, стоит $1300. ну, $300, если вам только постгрес, а другие базы не нужны.
Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

49. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Аномномномнимус (?), 19-Окт-18, 17:58 
Какие-то мудовикипедисты выпилили его из wiki, хотя в кэше поиска гугл выдаёт превьюшку, что оно было и на русском
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

95. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Аноним (95), 20-Окт-18, 12:41 
А не сравнивал с tora, как оно по возможностям?
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

32. "Релиз СУБД PostgreSQL 11"  +4 +/
Сообщение от Аноним (32), 19-Окт-18, 16:59 
Нормальный pg admin это тот, который на зарплате, например.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

34. "Релиз СУБД PostgreSQL 11"  –2 +/
Сообщение от Цезий Родонович (?), 19-Окт-18, 17:19 
Дайте UNDO !!!
Кто скажет, есть табличка статусов, 2000 строк, обновляются половина каждые 10 секунд, и читаются постоянно, как запилить что бы оно не умирало?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Аноним (27), 19-Окт-18, 17:23 
Автовакуум поставить очень часто. Вот и всё. И вообще, иногда полезно читать документацию.
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

87. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Цезий Родонович (?), 20-Окт-18, 10:25 
Так жопа получается, непрерывно работает вакум на одной таблице, а  базе еще кроме этого много чем нужно заниматься :)
и мне нужно в одной таблице (большой), часто у 5 % строк менять статусы поле число 0,1,2,3
какого хрена таблица растет ппц как?
и что теперь, вакумы работают непрерывно, а базе данных что делать больше ничего не надо?
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

120. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Мудила (?), 20-Окт-18, 20:37 
Но тут гонка получается. Один процесс лепит новые строки, под которые нужны новые или "удалённые" страницы: нет возвращённых страниц -- тогда нужно выделять новые. Другой должен успевать очищать страницы с удалёнными и ненужными строками. Баланс между ними настраивается стоимостью операций. В результате можно добиться, чтобы автовакуум был в приоритете, но тогда снизится производительность записи свежих данных. Поэтому выбор прост -- либо быстрее запись и файл будет пухнуть, либо пухнуть не будет (вернее будет существенно медленней пухнуть), но скорость записи на пиках просядет. У вас, насколько я понял, нагрузка равномерная и постоянная, а не периодическая. Поэтому, по-моему, вам подход с разрастанием файла вряд ли подойдёт; дайте больше шансов автовакууму успевать чистить файл. Повышайте лимит операций и снижайте время "сна", ну и памяти больше выдайте автовакууму (сразу в разы больше, а потом снижайте до приемлемого уровня). Настройка порогов включения, думаю, никаких сложностей само по себе не вызовет -- всё очевидно.
Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

37. "Релиз СУБД PostgreSQL 11"  +2 +/
Сообщение от Аноним (27), 19-Окт-18, 17:25 
Чем undo-то лучше? Вы даже самому себе этого объяснить не сможете. Потому что понятия не имеете, как Сегменты отката в Оракле работают.
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

39. "Релиз СУБД PostgreSQL 11"  –4 +/
Сообщение от Цезий Родонович (?), 19-Окт-18, 17:35 
Имею, Oracle DBA уже 20 лет как :)
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

42. "Релиз СУБД PostgreSQL 11"  +2 +/
Сообщение от Аноним (27), 19-Окт-18, 17:46 
И что с того? То, что вы имеете 45-ть лет вождения жигулей на дачу не делает из вас раллийного гонщика. Сами ведь понимаете.
Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

47. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 19-Окт-18, 17:55 
На DBA об этом знать ничего и не требуется.
Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

38. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от PereresusNeVlezaetBuggy (ok), 19-Окт-18, 17:28 
Держите UNDO:

                                                               ##
                                                               ##
                                                               ##
                           ######################################
                        #########################################
                      ###########################################
                    #############################################
                   ##########                                  ##
                 ########                                      ##
                 #######                                       ##
                 #####
                #####
                #####
                ####
                ####
                 ###
                 ####
                  ####
                   ###
                    ####                                       ##
                      #####                                    ##
                        #########################################
                           ######################################
                                                               ##
                                                               ##
                                                                
                ###                                            ##
                ###                                            ##
                ###                                            ##
                #################################################
                #################################################
                ###                                     #########
                ###                                  ############
                                                  ###############
                                               ################
                                              ###############
                                          ################
                                        ###############
                                     ###############
                                 ################
                               ###############
                            ###############
                         ###############
                      ###############                          ##
                    ###############                            ##
                 ################                              ##
                #################################################
                #################################################
                                                               ##
                                                               ##
                ###                                            ##
                ###                                            ##
                ###                                            ##
                #################################################
                #################################################
                #################################################
                #################################################
                ###                                            ##
                ###                                            ##
                ###                                            ##
                ###                                            ##
                ###                                           ###
                ####                                         ####
                 ###                                         ###
                 ####                                       ####
                  #####                                   #####
                   ######                               #######
                    ##########                     ##########
                    #############               #############
                      #####################################
                        #################################
                          #############################
                              #####################
                                  #############
                               ###################
                           ###########################
                        #################################
                      #####################################
                     ###########                 ###########
                   #######                             #######
                  #####                                   #####
                 ####                                       ####
                 ###                                         ###
                ###                                           ###
                ###                                            ##
                ###                                            ##
                ###                                           ###
                 ###                                         ###
                 ####                                       ####
                  #####                                   #####
                   #######                             #######
                    #########                       #########
                     #######################################
                       ###################################
                         ###############################
                             #######################
                                  #############

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

40. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Аноним (40), 19-Окт-18, 17:37 
Я сделал UNDO, но потом случайно запустил, поэтому опять ничего нет...
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

56. "Релиз СУБД PostgreSQL 11"  –4 +/
Сообщение от пох (?), 19-Окт-18, 18:17 
> Дайте UNDO

это из той же серии где и vacuum full; reindex;

> как запилить что бы оно не умирало?

никак. Или сменить базу данных на такую, авторы которых не изобретали time travel или хотя бы исправили ошибки молодости.

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

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

59. "Релиз СУБД PostgreSQL 11"  +2 +/
Сообщение от Аноним (27), 19-Окт-18, 18:32 
Ну к чему эту чушь транслировать? Вы же не разбираетесь в вопросе совсем. Автовакуум полностью эту проблему решает сейчас. Vacuum Full совсем про другое. И в Оракле нечто подобное тоже приходится делать. До 10-той версии это было крайне мутурное, к слову, занятие.
Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

75. "Релиз СУБД PostgreSQL 11"  –2 +/
Сообщение от пох (?), 19-Окт-18, 22:36 
в том и дело что не решает. Проблему раздувания стора, я имею в виду, при банальных апдейтах (причем вовсе не PK, а вообще неиндексированного поля) и, как следствие - тормозов даже при банальном индексном селекте. Потому что индекс, внезапно, у нас отрос в десятки раз больше чем на самом деле надо.

в орацле приходится делать в других случаях и случаи эти изрядно небанальны, если не сказать извратны. Неудивительно что и делается через задницу.

В innodb вообще не приходится - другая конструкция хранилки.

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

83. "Релиз СУБД PostgreSQL 11"  –2 +/
Сообщение от Мудила (?), 19-Окт-18, 23:38 
Ну, ё-маё, ну, ребята, читайте доки. Нет там никакого "раздувания стора". Если вы не обновляете статистику в соответствии с развитием модели, то, да, вы получаете снижение адекватности "разборщика" запросов. Это настолько очевидные вещи, что смешно о них тут упоминать.
Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

99. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (98), 20-Окт-18, 13:32 
> Нет там никакого "раздувания стора"

Мамкин dba пытается спорить о вкусе устриц с теми, кто их таки ел?

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

105. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Мудила (?), 20-Окт-18, 14:46 
Очень уныло и не понятно к чему.
Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

117. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Аноним (98), 20-Окт-18, 18:47 
Зато твой ник очень в тему, да.
Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

121. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Мудила (?), 20-Окт-18, 20:42 
Кластерные индексы что в Инно, что Сиквеле всё равно нужно обслуживать. В Оракле же ситуация с индексами очень похожа на Слона. Но, и тут я спорить не буду, Оракл значительно быстрее, но он в совсем другой лиге. В Оракле как раз крайне банальны. Куча и индексы по ней очень быстро расходятся под высокой нагрузкой. Но это всё неизбежно. Другое дело, что Оракле это от версии к версии всё больше делается само.
Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

61. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 19-Окт-18, 18:56 
А, извините, переоценил. Вам, насколько я понял, сама концепциям мультиверсионности аппетит испортила. Ну так, дерзайте, делайте что-то другое.
Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

77. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от пох (?), 19-Окт-18, 22:39 
не сама концепция, а последствия конкретно этой ее реализации. Образца 1995го года. Что сейчас нельзя сделать эффективно работающую - очень сомневаюсь.

> Ну так, дерзайте, делайте что-то другое.

вам миллиона существующих storage egnines мало?

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

82. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Аноним (79), 19-Окт-18, 23:33 
У нас и сейчас всё работает прекрасно.
Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

65. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Аноним (65), 19-Окт-18, 20:40 
Если данные условно временные, можете использовать UNLOGGED таблицы (не генерируют события WAL и при фейлах чистятся).

Для частых обновляющихся действий довольно неплохо подходит.

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

70. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Аноним (69), 19-Окт-18, 22:03 
Поменять подход не пробовали?
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

88. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Цезий Родонович (?), 20-Окт-18, 10:31 
Дохрена чего пробовали, но вот НАДО, очень, при том что есть и оракл, на тех же задачах, на гораздо  более слабом железе, у него не возникает проблем совсем никаких,
без холиваров, нравится постгрес, для небольших задач где только вставки-запросы, все хорошо, sql возможностями нравится и т.д.
Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

90. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Цезий Родонович (?), 20-Окт-18, 10:58 
Кортежей доступно    2130    
«Мертвых» кортежей    206960    
Последняя автоочистка    2018-10-20 10:55:03.599286+03    
Размер таблицы    114 MB

автовакум работает практически непрерывно, 2000 строк Карл!!!, 114 mb
как победить? такая таблица с таким режимом работы нужна.

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

92. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Forthemail (ok), 20-Окт-18, 11:24 
Как часто апдейты идут?
Типичный апдейт покажите запросом.
Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

93. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Цезий Родонович (?), 20-Окт-18, 11:40 
Я же писал уже задержку сдедал, не чаще чем 30 сек
в цикле от 30% до 100% строк  
update po.status set last_send_time=, ....= where id=:id по примари кей
ну очень нужна таблица статусов
Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

106. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Мудила (?), 20-Окт-18, 14:49 
Режим изоляции какой? Как транзакция разграничена? И разграничена ли вообще?
Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

114. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Forthemail (ok), 20-Окт-18, 17:48 
Вы транзакцию закрываете? Commit есть?
То что наблюдаете очень похоже на типичный недосмотр, нет коммита в коннекте. Апдейты делаете, а транзакцию не закрываете.
Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

135. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Мудила (?), 21-Окт-18, 23:18 
Да-да-да. Поэтому автовакуум и держит всю это помойку нетронутой.
Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

131. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от smit (??), 21-Окт-18, 17:57 
Сделайте отдельную таблицу из двух полей: ID и STATUS.
Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

103. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Мудила (?), 20-Окт-18, 14:23 
Ещё раз, читайте как настраивать автовакуум. Покажите тут действующие настройки.
Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

108. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Мудила (?), 20-Окт-18, 15:11 
Давайте попробуем разобраться. Версия Слона у вас какая? Что вас конкретно не устраивает? То, что файл пухнет? Сценарий ваш довольно типичен и к такому поведению при адекватных настройках приводить не должен.
Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

74. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Аноним (74), 19-Окт-18, 22:25 
Тот случай Когда архитектор должен повеситься от стыда
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

89. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Цезий Родонович (?), 20-Окт-18, 10:47 
Или его пристрелят бизнесс процессы которые не смогут подстроится под кривизну архитектуры СУБД
Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

94. "Релиз СУБД PostgreSQL 11"  –2 +/
Сообщение от Andrew (??), 20-Окт-18, 11:44 
Вас должен спрасти ZHeap. Прототип показали в марте, и уже тогда было понятно, что в 11 версию оно не попадает. Но всё-ещё есть надежда, что к 12 версии его таки успеют допилить.

Если пропустили, то анонс был тут: https://www.enterprisedb.com/blog/zheap-storage-engine-provi...
Текущий статус тут: https://wiki.postgresql.org/wiki/Zheap
За прогрессом следить тут: https://github.com/EnterpriseDB/zheap

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

127. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от nox (??), 21-Окт-18, 12:54 
Ваша проблема, на самом деле, в дизайне. Добавьте поле last_updated или insert_ts и замените UPDATE на INSERT, а запросы на чтение замените на выборку только самого актуального результата. При INSERT вакуум не работает, а удаление старых записей (и запуск вакуума) можно сделать по крону в периоды наименьшей нагрузки и чтобы удалял все и сразу (плюсом будет еще и то, что все удаляемые строки будут к конце таблицы, так что длинных блокировок не будет)

А по хорошему, постгрес не для этой задачи, возьмите другую БД под именно этот функционал и не делайте себе мозг.

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

130. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Мудила (?), 21-Окт-18, 14:32 
Это очень плохое и некомпетентное предложение.
Ответить | Правка | ^ к родителю #127 | Наверх | Cообщить модератору

143. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от nox (??), 22-Окт-18, 16:39 
> Это очень плохое и некомпетентное предложение.

Сказал человек с ником "Мудила"
Обоснуйте тогда, что ли

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

145. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 22-Окт-18, 17:46 
Ставить диагноз, когда потциент слился в неизвестном направлении, даже не расписав, что его конкретно не устраивает, занятие бесполезное. "Оракле ДБА" с седыми яйцами, вроде как, не понравилось что "файл разрастается". Ну так замена delete/insert на insert точно ситуацию не улучшит (инсерты точно будут требовать новых страниц, и проблему с устаревание нужно будет решать врукопашную; этим обычно админы Сиквела любят страдать -- читать доки для них сложнее, чем невообразимо идиотские триггеры лабать). В действительности, по-моему, никакой проблемы у жалобщика со Слоном нет, кроме того факта, что Слона он даже минимально не пытался настроить, а с логикой модели у него что-то явно не так (видимо, есть застарелая длительная транзакция, которая мертвые кортежи держит). Потому как движок Слона даже с умолчальными настройками автовакуума с подобным справляется вообще без проблем. Сам проверил: сделал отношение с несколькими тысячами строк и менял в них по циклу значение, выбирая произвольно по ключу (обновление одной строки за одну транзакцию). Ни тормозов на выборках, ни какого-то роста размера файла за час нагрузки получить не удалось. Это плёвая задача. Оно вообще никак особо на загрузке сервера не сказалась. Да и к тому же оставляет массу возможностей по оптимизации: хошь периодичность чекпоинтов повысь и тогда вообще ничего на диск падать не будет, хошь приоритет автовакуума подними -- всё будет чиститься влёт и файл расти будет очень умеренно.
Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

146. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 22-Окт-18, 17:49 
Up: неверное выразился -- периодичность чекпоинтов нужно понижать, т.е. повышать промежутки между ними.
Ответить | Правка | ^ к родителю #145 | Наверх | Cообщить модератору

148. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от nox (??), 22-Окт-18, 17:53 
Ну так вот и я о том же. Просто топикстартер жаловался, что у него вакуум не устраивает, что он распространяется на всю базу и частый запуск ему мешает или не работает, т.к. блокировки. В этом плане моё решение работает как раз норм, т.к. можно контролировать когда делать delete и соответственно вакуум (просто как идея, я ж хз что у него за данные и за модель)

Но вообще да, Слон спокойно справляется с такими вещами, более того, у меня была таблица с 5 млрд строк и 50к апдейтов в секунду - каждый апдейт 5Мб размером и ничего - всё работало и не жужжало и место особенно сильно не ело

Просто Мудилы и ДБА с яйцами видать не очень умеют доки/код читать - вакуум простая штука, пару дней курения мануалов, на крайняк почитать немного кода - и всё становится ясно - где, что и как работает и за что отвечает

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

149. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от nox (??), 22-Окт-18, 18:02 
> В этом плане моё решение работает как раз норм, т.к. можно контролировать
> когда делать delete и соответственно вакуум (просто как идея, я ж
> хз что у него за данные и за модель)

Забыл уточнить - у него UPDATE, то есть он часто и много делает UPDATE. Если делать часто INSERT, но редко и много DELETE и сразу после этого вакуум, то файл будет расти, но только в периоды между запусками вакуума

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

151. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от пох (?), 22-Окт-18, 22:04 
> то файл будет расти, но только в периоды между запусками вакуума

если мы правильно угадали его проблему (что это именно из-за особенностей стора, а не, действительно, "ой, commit забыли") - не будет (будет один раз, до первого delete ; vacuum).

vaccum прошел - следующие insert попадут в области того, что недавно delete, ничего особо заметно расти не будет.

и выполняется он при таком раскладе быстрее. Но решеньице, прямо скажем, выглядит кривоватенько.

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

156. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 23-Окт-18, 11:41 
Настройка стоимости операции для (авто)вакуума сделает тоже самое, только скрипты плодить и от Update-а отказываться не нужно будет.
Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

129. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Мудила (?), 21-Окт-18, 14:30 
Ладно, понял, что осмысленно диалога "DBA с двадцатилетним стажем" не выйдет.
Просто накрутите
-- autovacuum_vacuum_cost_limit в десять раз (больше 1000) поставьте;
-- autovacuum_vacuum_cost_delay сделайте в районе 5--10.
Если не помогло, то предварительно всё же стоило убедиться, что проблема именно в недостаточно частой "уборке" файла отношения. Потому что подобное поведение может быть следствием очень длительной транзакции, которая работает по данным, которые вы часто изменяете, а значит -- это ошибка вашей модели и её нужно корректировать. В общем, не тупите и читайте документацию.
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

153. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Цезий Родонович (?), 23-Окт-18, 09:36 
Ну нету там длинных транзакций, нету инсертов, делейтов, много коротких апдейтов, и это НЕ единственная таблица, другим тоже нужны ресурсы процессора, память, вакумы, и т.д.
Вакуум на ней висит практически постоянно, и не успевает, блять 2000 строк уже 260MB, простенький запрос к этой таблице должен выполнятся мгновенно, а он задумывается
Ответить | Правка | ^ к родителю #129 | Наверх | Cообщить модератору

154. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Аноним (27), 23-Окт-18, 11:31 
Думаю, вы уже знаете, что в Слоне update-ов нет, а есть delete/insert. Как и все современные РСУБД Слон работает исключительно с кэшем буферов (не с диском), а синхронно пишет изменения только в WAL. Поэтому ваш характер нагрузки на нормально настроенном серваке не должен приводить к частым сбросам буферов в файл (и его росту) -- данные меняются в кэше и, по идее, их вообще не нужно сбрасывать в файл. Вам этого и нужно добиться. Увеличивайте а) время между чекпоинтами, б) размазывайте фактический сброс по этому времени сильнее, в) проверьте достаточно ли памяти вашим процессам автовакуума (см. логи на предмет ошибок недостатка памяти, их в таком случае будет очень много), г) настройте параметры вакуума для конкретного отношения (настройки выше проскакивали), д) чтобы HOT-механизм работал эффективней (а это как раз ваш случай, у вас же не меняются индексные поля), увеличивайте значение филфактора для данной конкретной таблички.
С много процессов параллельно пытаются эти ваши статусы менять?
Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

157. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Цезий Родонович (?), 23-Окт-18, 14:40 
есть и много процессов, но разные строки, read commited,
в данном конкретном случае, 2-3 процесса, (плюс позанимался, добавил нужных индексов для других таблиц, в целом уменьшилась нагрузка на сервер), сделал
alter table  set (autovacuum_vacuum_cost_limit = 1000);
alter table  set (autovacuum_vacuum_cost_delay = 5);
теперь автовакум не висит постоянно, остановил все сервисы, сделал VACUUM FULL
через пол дня:
Кортежей доступно    2130    
«Мертвых» кортежей    28101
vacuum verbose
найдено удаляемых версий строк: 0, неудаляемых - 30230,
какого хрена?, никто таблицу не блокирует
select * from pg_catalog.pg_locks l where l.relation=23037
пусто
Ответить | Правка | ^ к родителю #154 | Наверх | Cообщить модератору

158. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 23-Окт-18, 15:32 
Блокировки тут не причём.
Зомби-транзакции поищите. Всё же, очень похоже на то, что транзакции не фиксируются или разграничены не так, как вы себе представляете. Поэтому задействованные ими кортежи и не подвергаются уборке.
А vacuum full эти мёртвые кортежи убирает?
Понимаете, если у вас много обновляющих данные процессов в одном отношении, то подобная картинка вполне себе типична. В том, что в результате дофига хранится исторических данных, нет ничего ужасного и необычного. Их будет тем больше, чем больше параллельных процессов, работающих с отношением: им же всем нужно получить состояние кортежей на момент начала каждой из транзакций. Другое дело, что шлака столько не должно оставаться.
Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

159. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 23-Окт-18, 16:01 
Вот, скажем, началась у вас транзакция Т1. Она длиться, условно, 10 единиц времени. Через десять единиц времени она фиксируется.
T1 началась во время t1.
T2 началась в t1 + 1.
T3 : t1 + 2
T4 : t1 + 3.
Ну и т.д.
Т2 хочет видеть состояние БД на момент t1 + 1. И, соответственно, те кортежи, которые T1 похерила, но не зафиксировала, вакуум удалять не может -- они нужны T2, T3... И так по цепочке. В результате если у вас много процессов которые производят большое кол-во обновлений по ключу, то исторических "хвост" нужно будет держать весьма значительный.
На этом фоне замена обновление на вставку, а потом явное удаление устаревших событий, не кажется таким уж нелепым решением.
Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

160. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 23-Окт-18, 16:05 
А памяти у нас на серваке много? Значение maintenance_work_mem сколько выставлено? БД в кластере много?
Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

161. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Цезий Родонович (?), 26-Окт-18, 09:10 
Короче, нашел, в этой же базе но, вообще не имеюшее к этой таблице никакого отношения, "чужое" приложение после select-а не делает коммит. но у него свои таблицы и к моей никогда не обращается!!!
Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

162. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Forth (ok), 26-Окт-18, 10:24 
> Короче, нашел, в этой же базе но, вообще не имеюшее к этой
> таблице никакого отношения, "чужое" приложение после select-а не делает коммит. но
> у него свои таблицы и к моей никогда не обращается!!!

Чужое приложение научили делать commit? Помогло?


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

163. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Цезий Родонович (?), 26-Окт-18, 16:42 
Чужого разработчика надо пнуть, а потом чтобы обновилось на сотнях ПК, я рубал все их сессии, и пока не налезли опять, вакум проходил
но он же НИКАК не касается этой таблицы, оно делает ЗАПРОСЫ и к СВОИМ таблицам, короче бред какойто
Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

164. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Forth (ok), 26-Окт-18, 18:26 
> Чужого разработчика надо пнуть, а потом чтобы обновилось на сотнях ПК, я
> рубал все их сессии, и пока не налезли опять, вакум проходил
> но он же НИКАК не касается этой таблицы, оно делает ЗАПРОСЫ и
> к СВОИМ таблицам, короче бред какойто

Если дело в одной БД происходит и даже в разных схемах - бывает просто имена совпадают, допустим в вашей схеме (дефолтный public) есть таблица state и у него есть в его схеме таблица с тем же имененм, но в запросе указать схему чужой разраб забыл и обращается не к своей, потом получает не те колонки вылетает с софте ошибка и коннект с тразакцией теряется и висит бесконечно.

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

155. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 23-Окт-18, 11:38 
Не зря вас про уровень изоляции транзакции спрашивали. Если у вас много параллельных запросов на изменение, к тому же все они serializable, то что-то подобное может произойти. Если приложение работает через jdbc-драйвер нужно проверить какой режим изоляции для транзакций выбран.
Ответить | Правка | ^ к родителю #153 | Наверх | Cообщить модератору

136. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от лютый джо__ (?), 22-Окт-18, 07:11 
>есть табличка статусов, 2000 строк, обновляются половина каждые 10 секунд

Накукуй тут вообще реляционная субд?

Если нужна мегаскорость (ну там сотни тысяч запросов в сек с 1 сервера) любой in-memory KV носкль будет хорошо работать или вообще hashmap какой-нибудь с записью журнала и lazy-persistence.
10 строчек кода.

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

147. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (27), 22-Окт-18, 17:52 
Слон с этим тоже работает без проблем. Собственно, как раз это самое lazy persistence и происходит: блоки из буферов практически с файл и не успевают попадать большую часть времени. Там фактический I/O с диском получается вообще мизерный.
Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

76. "Релиз СУБД PostgreSQL 11"  –2 +/
Сообщение от Аноним (78), 19-Окт-18, 22:38 
Уже в Debian, Mandriva и, как ни странно, Termux:

https://repology.org/metapackage/postgresql/history

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

91. "Релиз СУБД PostgreSQL 11"  +3 +/
Сообщение от Andrew (??), 20-Окт-18, 11:20 
Переводчика на мыло! Зачем так переводить, что смысл кардинально меняется?

>> Добавлен новый вид хранимых процедур, позволяющих использовать транзакции.

Никакого _нового_ вида хранимых процедур не добавляли. Добавили поддержку управления транзакциями из хранимых процедур, и всё. Английское "SQL procedures"- это любые хранимые процедуры, написанные на любом поддерживаемом языке, кроме динамически загружаемых из внешних модулей процедур, написанных, как правло, на C.

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

В оригинале было "incremental bulk data loading". Инкрементальной пакетной, а не просто пакетной- разница очень существенна.

>> Для определения хранимых процедур с транзакциями добавлена новая команда CREATE PROCEDURE.

Эм... Вообще-то она не новая, она там с незапамятных времен. В оригинале было всего-лишь "SQL procedures can be created using the CREATE PROCEDURE command". То есть просто напомнили, как их создавать.

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

104. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Мудила (?), 20-Окт-18, 14:43 
Ваш вариант, по-моему, не лучше.
Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

123. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Andrew (??), 20-Окт-18, 22:34 
Мой вариант, простите, чего именно? Я, кажется, не предлагал альтернативных вариантов перевода, а лишь указал на ошибки в оригинальном переводе из новости...
Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

101. "Релиз СУБД PostgreSQL 11"  –3 +/
Сообщение от Аноним (100), 20-Окт-18, 13:54 
CockroachDB через пару лет отправит на свалку этого динозавра.
Из Postgresql уже песок сыпется
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

102. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Цезий Родонович (?), 20-Окт-18, 14:16 
https://opennet.ru/opennews/art.shtml?num=46529

"11.05.2017 11:50  Первый стабильный выпуск отказоустойчивой СУБД CockroachDB "
"Из ограничений CockroachDB отмечается плохая пригодность для решений, требующих очень низкого времени отклика при выполнении операций записи и чтения. CockroachDB также плохо адаптирован для нагруженных систем обработки аналитической информации (OLAP), манипулирующих сразу большими срезами данных, и плохо оптимизирован для выполнения сложных SQL-запросов со слиянием нескольких таблиц "

Вы об этом?

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

122. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Анонимно (?), 20-Окт-18, 21:14 
Да, то было в первой версии.
Прикинь, база маскируется под PostgreSQL, а ведет себя как распределенная, строго консистентная база данных.
Маскируется она полностью, реализуя протокол PostgreSQL.
Запускаешь 1 бинарник и у тебя база с мониторингом, которой приятно пользоваться.
Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

132. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от пох (?), 21-Окт-18, 19:49 
> Да, то было в первой версии.

а сейчас что?

> Прикинь, база маскируется под PostgreSQL, а ведет себя как распределенная, строго консистентная база данных.

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

> Маскируется она полностью, реализуя протокол PostgreSQL.

"но зачем?!"
неужели это было проще, чем написать свои коннекторы для c/c++/пехепе/пихон/жабы (на самом деле не "и", а "сперва или, а потом как пойдет", поскольку вряд ли одному проекту нужно больше пары из списка ? Или протокол постгреза оказался чем-то удивительно хорош и приятен?
(вот уж вряд ли)

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

152. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от KonstantinB (ok), 23-Окт-18, 04:46 
Протокол постгреса весьма приятен и хорошо задокументирован. Null terminated-строками только несколько злоупотребляют, но это не страшно.
Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

111. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (111), 20-Окт-18, 15:31 
Что значит "Обеспечена корректная маршрутизация операций"? Оно и раньше работало, вот только транзакции там не работали, это оно или о чём речь?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

124. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (124), 21-Окт-18, 02:28 
Для венды так и не сканпеляли. :( Чё за расизм?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

126. "Релиз СУБД PostgreSQL 11"  +1 +/
Сообщение от Andrey Mitrofanov (?), 21-Окт-18, 09:56 
> Для венды так и не сканпеляли. :( Чё за расизм?

Это пазитиффная дискриминация, дурашка.

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

141. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Аноним (141), 22-Окт-18, 11:38 
https://www.enterprisedb.com/download-postgresql-binaries

Есть для винды и макоси, для линукса пока нету :(

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

125. "Релиз СУБД PostgreSQL 11"  +/
Сообщение от Ддд (?), 21-Окт-18, 03:02 
Как была тормозной херней так и осталась
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

140. "Релиз СУБД PostgreSQL 11"  –1 +/
Сообщение от Аноним (141), 22-Окт-18, 11:37 
Где бинарные сборки?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру