The OpenNET Project / Index page

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

Релиз СУБД PostgreSQL 11

19.10.2018 11:06

После года разработки опубликована новая стабильная ветка СУБД PostgreSQL 11. Обновления для новой ветки будут выходить в течение пяти лет до октября 2023 года. Основное внимание при подготовке новой ветки было уделено расширению функциональности в областях управления очень большими базами данных и разработки приложений для масштабируемой обработки больших данных.

Основные новшества:

  • Добавлена возможность применения JIT-компиляции (Just-in-Time) для ускорения выполнения некоторых выражений в процессе обработки SQL-запроса. Например, JIT применим для ускорения выполнения выражений внутри блоков "WHERE", в выходных списках (target lists), агрегатных выражениях и проекциях. JIT также задействован для ускорения некоторых внутренних операций. Предложенный JIT-компилятор построен на основе наработок LLVM и для включения требует установки дополнительных зависимостей, связанных с LLVM. Включение осуществляется настройкой "jit = on" в файле конфигурации или командой "SET jit = on" в интерактивном сеансе;
  • Добавлен новый вид хранимых процедур, позволяющих использовать транзакции. Процедуры определяются с использованием синтаксиса SQL и позволяют использовать все средства управления транзакциями. Поддержка транзакций в процедурах даёт возможность создавать более продвинутые серверные обработчики, например, для пакетной загрузки данных. Для определения хранимых процедур с транзакциями добавлена новая команда CREATE PROCEDURE. Для выполнения процедуры используется команда CALL. К SQL-процедурам также можно обращаться из хранимых процедур на PL/pgSQL, PL/Perl, PL/Python и PL/Tcl;
  • Улучшения, связанные с секционированием (партицированием):
    • Реализована поддержка секционирования данных по хэшу, которая позволяет секционировать таблицы не только по диапазонам значений и спискам, но и по произвольным ключам.
    • Обеспечена корректная маршрутизация операций INSERT, UPDATE и COPY для секционированных таблиц, обрабатываемых с использованием модуля 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".


  1. Главная ссылка к новости (https://www.postgresql.org/abo...)
  2. OpenNews: Релиз СУБД PostgreSQL 10
  3. OpenNews: Яндекс опубликовал Odyssey, многопоточный балансировщик соединений для PostgreSQL
  4. OpenNews: Для PostgreSQL предложено новое хранилище zheap
  5. OpenNews: Для PostgreSQL подготовлено расширение TopN
  6. OpenNews: Атака по майнингу криптовалюты на незащищённых серверах PostgreSQL
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/49462-postgresql
Ключевые слова: postgresql, database
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (159) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Dmrjan (?), 14:02, 19/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    Буду ждать PostgreSQL Pro.
     
     
  • 2.97, Аноним (97), 13:14, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я вот не пойму, почему этих ребят за нарушение тм в суд не пригласили?
    У них договорённости какие-то или они на территории США не распространяются?
     
     
  • 3.137, hiveliberty (ok), 10:55, 22/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да, тоже интересно было.. Но, вот почему, как я понимаю: https://postgrespro.com/about
    С официального https://www.postgresql.org/docs/ даже линк на доки на https://postgrespro.com
     
  • 3.138, Andrey Mitrofanov (?), 10:58, 22/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Я вот не пойму, почему этих ребят за нарушение тм в суд

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

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

     
  • 3.142, KonstantinB (??), 16:30, 22/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Нарушение, простите, чего? BSDL?
     
     
  • 4.144, Andrey Mitrofanov (?), 16:51, 22/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Нарушение, простите, чего? BSDL?

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

     

  • 1.3, Ivan (??), 14:06, 19/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Когда движок перепилят, что бы избавится от вакуума?
     
     
  • 2.6, Ilya Indigo (ok), 14:19, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хотел тоже спросить.
     
  • 2.7, Dmrjan (?), 14:22, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Когда движок перепилят, что бы избавится от вакуума?

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

     
     
  • 3.13, Ilya Indigo (ok), 15:09, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы говорите про следствие (вакум), а автор спросил про причину (движок).
     
  • 3.17, Аноним (17), 15:44, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    С текущим движком постгри всё так. О том и речь, чтобы сделать наконец нормальный движок как в приличных СУБД.
     
     
  • 4.27, Аноним (27), 16:49, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А "Нормальные" это какие?
     
     
  • 5.67, _dz (?), 21:32, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, Оракл, видимо.
     
     
  • 6.79, Аноним (79), 23:09, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это который ORA-01555; Snapshot too old? Нет, такой движок нам не нужен :-)
     
     
  • 7.85, Мудила (?), 23:42, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну ведь это тоже чисто "проблема реализации". Сделайте Сегмент отката пожирнее.
     
     
  • 8.133, anonymous (??), 20:39, 21/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Нет это не сегементы отката пожирнее Если бы так то была бы ошибка о нехватки... текст свёрнут, показать
     
     
  • 9.134, Мудила (?), 23:09, 21/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Конкретней Это ошибка, связанная с тем, что данные были из Сегмента отката выте... текст свёрнут, показать
     
  • 7.96, 123456789 (??), 12:54, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    ORA-600 же
     
  • 5.68, Аноним (68), 21:36, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > А "Нормальные" это какие?

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

     
  • 2.12, Andrey Mitrofanov (?), 15:02, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Когда движок перепилят, что бы избавится от вакуума?

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

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

     
     
  • 3.14, Ilya Indigo (ok), 15:11, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    И как только InnoDB без всяких вакуумов справляется, предоставляя транзакционность и прочее нужное?
     
     
  • 4.18, morruth (?), 15:53, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +8 +/
    вы таки будете смеяться, но вакуум там есть, просто называется по другому
     
  • 4.20, ajp (?), 15:56, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +5 +/
    И только почему-то в InnoDB нужно периодически запускать optimize.
     
  • 4.31, Аноним (27), 16:55, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ильюша, аналог "вакуума" есть во всех mvcc-рсубд. Это основа подхода -- сохранять исторические данные для организации многоверсионности. Реализаций существует несколько -- ни одна из них не являет особых преимуществ перед другими.
     
     
  • 5.41, Ilya Indigo (ok), 17:46, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Совсем не лучше?
    https://habr.com/company/southbridge/blog/322624
     
     
  • 6.44, Аноним (27), 17:49, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хабр читать не буду. Хотите что-то узнать попробуйте осмысленно пересказать мне о чём там, я может и отвечу что-нибудь. Хотя не очень понимаю зачем мне этим культпросветом заниматься.
     
     
  • 7.55, Ilya Indigo (ok), 18:14, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Наиболее важное архитектурное отличие заключается в том, что Postgres напрямую с... большой текст свёрнут, показать
     
     
  • 8.57, Аноним (27), 18:17, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Замечательно, что вы освоили ctrl-c и ctrl-v, но что из этого вы поняли Вы крит... текст свёрнут, показать
     
  • 8.58, Аноним (27), 18:29, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Объясню В Оракле записи в Сегмент отката обслуживается на общих основаниях , т... текст свёрнут, показать
     
  • 8.60, Аноним (27), 18:41, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У Инно ещё и косяки с синхронизацией Нужно быть отчаянным авантюристом, чтобы И... текст свёрнут, показать
     
     
  • 9.86, Ага (?), 01:20, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Достаточно провести нагрузочное тестирование перед вводом в прод ну и не пользов... текст свёрнут, показать
     
  • 8.62, Аноним (27), 18:59, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Сама по себе концепция кластерного индекса не делает Инно не хуже, не лучше, чем... текст свёрнут, показать
     
  • 6.46, Аноним (27), 17:53, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ААААааааа.... Чуваки из Убера на полном серьёзе пишут, что транзакционность это ненужное фуфло, потому... что замедляет запись )))))))) Вот новость-то.
     
     
  • 7.69, Аноним (69), 21:59, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да и флаг им в руки.
     
  • 7.100, Аноним (100), 13:51, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А ты свои 10 записей пишешь и тебе хватает. Как поработаешь с нагруженными прилржениями, поймешь, что это такое и какая нужна производительность
     
  • 7.113, Анонимно (?), 15:39, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ты, наверное админ, который про базы только в школе слышал и наверное тебе не рассказали что консистентность можно поддерживать разными способами
     
  • 4.45, Аномномномнимус (?), 17:52, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тоже расскажи, а то посмотришь на хард после OPTIMIZE TABLE и прям диву даёшься
     
     
  • 5.54, Аноним (27), 18:14, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё раз. Это общая проблема. Никто её пока как-то сильно лучше других не решил. Статистику нужно обновлять, индексы обновлять, данные отмены где-то и как-то хранить, а потом очищать. У всех одинаковые проблемы.
     
  • 5.109, Аноним (109), 15:27, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    InnoDB на SSD или при преимущественно рандомных выборках не-range на любом носителе OPTIMIZE TABLE наксер не нужен, поскольку фрагментация роли не играет. Повторное использование страниц при этом есть.

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

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

     
  • 2.15, пох (?), 15:14, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    да, я тоже что-то не понял, где в списке новостей - "1. vacuum deprecated и назначен к выпиливанию в 11.1" - сопровождавшее все выпуски, кажется, начиная с 8. Наверное, автор новости просто невнимательно читал оригинал. ;-)


     
     
  • 3.112, Аноним (109), 15:31, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В пользу автовакуума, угу, который один ксер тот же вакуум. Как вы с этим кактусом живёте. Ну ладно на хдд фрагментирование допустим таблиц InnoDB требовало аккуратного подхода, но вот на SSD-то оно не актуально уже.
     
     
  • 4.116, пох (?), 18:45, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    вы свое "фрагментирование" (которое многозадачной системе, вообще-то, изрядно до лампы) с бесконечным разрастанием таблиц и их индексов из-за банального update -то не путайте.

     
  • 2.16, Catwoolfii (ok), 15:35, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Когда EnterpriseDB допилит zheap и протолкнет его в ваниль, тогда и будет...
     
     
  • 3.33, Аноним (27), 17:18, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем? Чем "вакуум"-то мешает жить тем, кому он... мешает жить? Чем Сегменты откаты в Оракле удобней? Обычно про вакуум визжат ничего сложней Дельфина никогда не пробовавшие.
     
     
  • 4.73, пох (?), 22:25, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Чем "вакуум"-то мешает жить

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

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

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

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

     
     
  • 5.80, Аноним (79), 23:14, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > тем что жрет ресурсы как не в себя

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

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

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

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

    vacuum full не нужен

    > reindex

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

     
     
  • 6.98, Аноним (98), 13:27, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > у всех работает

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

     
     
  • 7.107, Catwoolfii (ok), 15:07, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вообще то он работает, просто файлы остаются "разряженные"
     
  • 5.128, Мудила (?), 14:19, 21/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Т. е. по вашему получается, что обслуживание Сегментов отката даром даётся ))) Ну, оно как-то само там что-то с собой делает. И хватит тут кичится своим невежеством и непрофессионализмом. Если у вас что-то не получается, то слушайте тех, у кого получается, а не хамите, как пэтэушник. "Проблема вакуума" непонятна тем, кто по этой проблеме и пары страниц не удосужился прочитать, но рассказывает тут какой он "практик". Даже не смешно уже.
     
     
  • 6.150, пох (?), 21:45, 22/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ну, скажем так - оно во-первых вполне предсказуемое, во вторых, в самом банальном варианте таки даром, да - напоминаю, что постгрез раздувает и стор и индекс на банальном update не-ключевых полей. Без всяких параллельных транзакций и длительных блокировок - просто потому что вот так он у него устроен. В этом он совершенно уникален, кто-то там своего PhD в 95м за эту фичу получил.

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

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

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

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

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

     
  • 2.28, Аноним (27), 16:50, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это уже очень давно произошло.
     
  • 2.35, Аноним (27), 17:19, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Иван, а что вы знаете о СУБД вообще? Хоть что-нибудь знаете, а? Ну хоть чуть-чуть?
     
  • 2.43, Аноним (43), 17:49, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Другой вопрос, когда появится поддержка других хранилищь, помимо блочных устройств? Энергонезависимую память уже втыкают в слот оперативной. MySQL уже несколько десятков лет умеет работать с оперативкой.
     
     
  • 3.51, Аноним (27), 18:07, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А как понять "умеет работать с оперативкой"? Все современные СУБД "умеют работать с оперативкой", с ней только и работают.
     
  • 3.78, Аноним (78), 22:44, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А что, оперативка и NVME вдруг перестали работать как блочные устройства?
     
     
  • 4.115, Аноним (115), 18:24, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    т.е. вы предлагаете то, что можно адресовать по-байтно, адресовать по-блочно, чтобы только ничего не переделывать?
     
     
  • 5.118, Мудила (?), 20:16, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    З а ч е м? Объём накладных расходов возрастает в десятки раз. Вы не задумывались почему так распространена постраничная адресация, а? Микроменеджмент всего это хозяйства будет занимать все ресурсы.
     

     ....большая нить свёрнута, показать (50)

  • 1.8, Ононимус (?), 14:27, 19/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +9 +/
    В интерфейс командной строки в дополнение к штатной команде "\q" добавлены более привычные для новичков команды "quit" и "exit".

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

     
     
  • 2.11, Аноним (11), 15:02, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +7 +/
    ...пока ждал - привык к \q)))
     
     
  • 3.19, morruth (?), 15:54, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +11 +/
    всегда по ctrl-D выходил :)
     
  • 2.21, 1 (??), 16:07, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +12 +/
    требую добавить :q
     
  • 2.139, Анонимусис (?), 11:11, 22/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ctrl + D Остальное для слабаков
     

  • 1.9, Аноним (9), 14:27, 19/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –9 +/
    >Добавлен новый вид хранимых процедур, позволяющих использовать транзакции

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

     
     
  • 2.22, Аноним (22), 16:19, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это вложенные транзакции, дурилка.
    И это очень круто.
     
     
  • 3.24, абв (?), 16:24, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Из описания новости не понятно ни черта.

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

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

     
     
  • 4.25, Аноним (22), 16:45, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых: https://www.postgresql.org/docs/11/static/xproc.html
    Во-вторых, в функции можно было, в процедуре - нет
     
     
  • 5.50, абв (?), 18:00, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Во-вторых, в функции можно было, в процедуре - нет

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

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

     
     
  • 6.52, Аноним (27), 18:08, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Значит, никогда ни транзактом, ни с пл-, ни с пг-сиквелом дел не имели. И с СУБД вообще. Зачем тогда вам разбираться в этих тонкостях?
     
     
  • 7.64, абв (?), 19:10, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Зачем тогда вам разбираться в этих тонкостях?

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

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

     
     
  • 8.71, Мудила (?), 22:12, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Исторически разница была в том, что функции можно было встраивать в SQL-выражени... текст свёрнут, показать
     
  • 8.72, Мудила (?), 22:19, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, я несколько не точно выразился Процедуры тоже можно было в SQL-код встраива... текст свёрнут, показать
     
  • 3.30, Аноним (27), 16:52, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не то чтоб очень круто, а "как в Оракле".
     
  • 3.81, Аноним (79), 23:29, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Это вложенные транзакции

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

     
     
  • 4.110, Аноним (109), 15:29, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Шёл 2018 год...
     

  • 1.10, Аноним (78), 14:33, 19/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > слияния хэшей

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

     
  • 1.23, абв (?), 16:20, 19/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > Добавлен новый вид хранимых процедур, позволяющих использовать транзакции.

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

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

     
  • 1.26, Rodegast (ok), 16:47, 19/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Когда выпустят нормальный PgAdmin?
     
     
  • 2.29, Аноним (27), 16:51, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А зачем он? Я DBeaver-ом пользуюсь. Для всего. И для Слона тоже. Вполне достаточно.
     
     
  • 3.48, Аномномномнимус (?), 17:57, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Оооо!!! Спасибо, похоже это то, что я давно хотел.
    А он умеет по SSH и через PHP-прокси в базы данных стучать, как Navicat?
     
     
  • 4.53, Аноним (27), 18:11, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю, не пробовал.
    А зачем это вот прям уметь? Туннель сторонними средствами можно ведь без проблем сделать, только порты пробросить.
     
     
  • 5.63, Аномномномнимус (?), 19:02, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Не на всех хостингах можно использовать SSH, а так же вертеть mysql как угодно, а в БД бывает надо поковыряться. И в итоге в худших случаях начинается цирк с "забекапить, скачать, развернуть, поправить, сбекапить, залить обратно, развернуть"
     
  • 4.66, й (?), 21:02, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    navicat, на минуточку, стоит $1300. ну, $300, если вам только постгрес, а другие базы не нужны.
     
  • 3.49, Аномномномнимус (?), 17:58, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Какие-то мудовикипедисты выпилили его из wiki, хотя в кэше поиска гугл выдаёт превьюшку, что оно было и на русском
     
  • 3.95, Аноним (95), 12:41, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А не сравнивал с tora, как оно по возможностям?
     
  • 2.32, Аноним (32), 16:59, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Нормальный pg admin это тот, который на зарплате, например.
     

  • 1.34, Цезий Родонович (?), 17:19, 19/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Дайте UNDO !!!
    Кто скажет, есть табличка статусов, 2000 строк, обновляются половина каждые 10 секунд, и читаются постоянно, как запилить что бы оно не умирало?
     
     
  • 2.36, Аноним (27), 17:23, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Автовакуум поставить очень часто. Вот и всё. И вообще, иногда полезно читать документацию.
     
     
  • 3.87, Цезий Родонович (?), 10:25, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Так жопа получается, непрерывно работает вакум на одной таблице, а  базе еще кроме этого много чем нужно заниматься :)
    и мне нужно в одной таблице (большой), часто у 5 % строк менять статусы поле число 0,1,2,3
    какого хрена таблица растет ппц как?
    и что теперь, вакумы работают непрерывно, а базе данных что делать больше ничего не надо?
     
     
  • 4.120, Мудила (?), 20:37, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Но тут гонка получается Один процесс лепит новые строки, под которые нужны новы... большой текст свёрнут, показать
     
  • 2.37, Аноним (27), 17:25, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Чем undo-то лучше? Вы даже самому себе этого объяснить не сможете. Потому что понятия не имеете, как Сегменты отката в Оракле работают.
     
     
  • 3.39, Цезий Родонович (?), 17:35, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Имею, Oracle DBA уже 20 лет как :)
     
     
  • 4.42, Аноним (27), 17:46, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    И что с того? То, что вы имеете 45-ть лет вождения жигулей на дачу не делает из вас раллийного гонщика. Сами ведь понимаете.
     
  • 4.47, Аноним (27), 17:55, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    На DBA об этом знать ничего и не требуется.
     
  • 2.38, PereresusNeVlezaetBuggy (ok), 17:28, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Держите UNDO code ... большой текст свёрнут, показать
     
  • 2.40, Аноним (40), 17:37, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я сделал UNDO, но потом случайно запустил, поэтому опять ничего нет...
     
  • 2.56, пох (?), 18:17, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Дайте UNDO

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

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

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

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

     
     
  • 3.59, Аноним (27), 18:32, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ну к чему эту чушь транслировать? Вы же не разбираетесь в вопросе совсем. Автовакуум полностью эту проблему решает сейчас. Vacuum Full совсем про другое. И в Оракле нечто подобное тоже приходится делать. До 10-той версии это было крайне мутурное, к слову, занятие.
     
     
  • 4.75, пох (?), 22:36, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    в том и дело что не решает. Проблему раздувания стора, я имею в виду, при банальных апдейтах (причем вовсе не PK, а вообще неиндексированного поля) и, как следствие - тормозов даже при банальном индексном селекте. Потому что индекс, внезапно, у нас отрос в десятки раз больше чем на самом деле надо.

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

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

     
     
  • 5.83, Мудила (?), 23:38, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну, ё-маё, ну, ребята, читайте доки. Нет там никакого "раздувания стора". Если вы не обновляете статистику в соответствии с развитием модели, то, да, вы получаете снижение адекватности "разборщика" запросов. Это настолько очевидные вещи, что смешно о них тут упоминать.
     
     
  • 6.99, Аноним (98), 13:32, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Нет там никакого "раздувания стора"

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

     
     
  • 7.105, Мудила (?), 14:46, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Очень уныло и не понятно к чему.
     
     
  • 8.117, Аноним (98), 18:47, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зато твой ник очень в тему, да ... текст свёрнут, показать
     
  • 5.121, Мудила (?), 20:42, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Кластерные индексы что в Инно, что Сиквеле всё равно нужно обслуживать. В Оракле же ситуация с индексами очень похожа на Слона. Но, и тут я спорить не буду, Оракл значительно быстрее, но он в совсем другой лиге. В Оракле как раз крайне банальны. Куча и индексы по ней очень быстро расходятся под высокой нагрузкой. Но это всё неизбежно. Другое дело, что Оракле это от версии к версии всё больше делается само.
     
  • 3.61, Аноним (27), 18:56, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А, извините, переоценил. Вам, насколько я понял, сама концепциям мультиверсионности аппетит испортила. Ну так, дерзайте, делайте что-то другое.
     
     
  • 4.77, пох (?), 22:39, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    не сама концепция, а последствия конкретно этой ее реализации. Образца 1995го года. Что сейчас нельзя сделать эффективно работающую - очень сомневаюсь.

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

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

     
     
  • 5.82, Аноним (79), 23:33, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У нас и сейчас всё работает прекрасно.
     
  • 2.65, Аноним (65), 20:40, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Если данные условно временные, можете использовать UNLOGGED таблицы (не генерируют события WAL и при фейлах чистятся).

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

     
  • 2.70, Аноним (69), 22:03, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Поменять подход не пробовали?
     
     
  • 3.88, Цезий Родонович (?), 10:31, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дохрена чего пробовали, но вот НАДО, очень, при том что есть и оракл, на тех же задачах, на гораздо  более слабом железе, у него не возникает проблем совсем никаких,
    без холиваров, нравится постгрес, для небольших задач где только вставки-запросы, все хорошо, sql возможностями нравится и т.д.
     
  • 3.90, Цезий Родонович (?), 10:58, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Кортежей доступно 2130
    «Мертвых» кортежей 206960
    Последняя автоочистка 2018-10-20 10:55:03.599286+03
    Размер таблицы 114 MB

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

     
     
  • 4.92, Forth (ok), 11:24, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Как часто апдейты идут?
    Типичный апдейт покажите запросом.
     
     
  • 5.93, Цезий Родонович (?), 11:40, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я же писал уже задержку сдедал, не чаще чем 30 сек
    в цикле от 30% до 100% строк  
    update po.status set last_send_time=, ....= where id=:id по примари кей
    ну очень нужна таблица статусов
     
     
  • 6.106, Мудила (?), 14:49, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Режим изоляции какой? Как транзакция разграничена? И разграничена ли вообще?
     
  • 6.114, Forth (ok), 17:48, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вы транзакцию закрываете? Commit есть?
    То что наблюдаете очень похоже на типичный недосмотр, нет коммита в коннекте. Апдейты делаете, а транзакцию не закрываете.
     
     
  • 7.135, Мудила (?), 23:18, 21/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да-да-да. Поэтому автовакуум и держит всю это помойку нетронутой.
     
  • 6.131, smit (??), 17:57, 21/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Сделайте отдельную таблицу из двух полей: ID и STATUS.
     
  • 4.103, Мудила (?), 14:23, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё раз, читайте как настраивать автовакуум. Покажите тут действующие настройки.
     
  • 4.108, Мудила (?), 15:11, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Давайте попробуем разобраться. Версия Слона у вас какая? Что вас конкретно не устраивает? То, что файл пухнет? Сценарий ваш довольно типичен и к такому поведению при адекватных настройках приводить не должен.
     
  • 2.74, Аноним (74), 22:25, 19/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тот случай Когда архитектор должен повеситься от стыда
     
     
  • 3.89, Цезий Родонович (?), 10:47, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Или его пристрелят бизнесс процессы которые не смогут подстроится под кривизну архитектуры СУБД
     
  • 2.94, Andrew (??), 11:44, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вас должен спрасти ZHeap. Прототип показали в марте, и уже тогда было понятно, что в 11 версию оно не попадает. Но всё-ещё есть надежда, что к 12 версии его таки успеют допилить.

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

     
  • 2.127, nox (??), 12:54, 21/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ваша проблема, на самом деле, в дизайне. Добавьте поле last_updated или insert_ts и замените UPDATE на INSERT, а запросы на чтение замените на выборку только самого актуального результата. При INSERT вакуум не работает, а удаление старых записей (и запуск вакуума) можно сделать по крону в периоды наименьшей нагрузки и чтобы удалял все и сразу (плюсом будет еще и то, что все удаляемые строки будут к конце таблицы, так что длинных блокировок не будет)

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

     
     
  • 3.130, Мудила (?), 14:32, 21/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Это очень плохое и некомпетентное предложение.
     
     
  • 4.143, nox (??), 16:39, 22/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Это очень плохое и некомпетентное предложение.

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

     
     
  • 5.145, Аноним (27), 17:46, 22/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ставить диагноз, когда потциент слился в неизвестном направлении, даже не распис... большой текст свёрнут, показать
     
     
  • 6.146, Аноним (27), 17:49, 22/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Up: неверное выразился -- периодичность чекпоинтов нужно понижать, т.е. повышать промежутки между ними.
     
  • 6.148, nox (??), 17:53, 22/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так вот и я о том же. Просто топикстартер жаловался, что у него вакуум не устраивает, что он распространяется на всю базу и частый запуск ему мешает или не работает, т.к. блокировки. В этом плане моё решение работает как раз норм, т.к. можно контролировать когда делать delete и соответственно вакуум (просто как идея, я ж хз что у него за данные и за модель)

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

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

     
     
  • 7.149, nox (??), 18:02, 22/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > В этом плане моё решение работает как раз норм, т.к. можно контролировать
    > когда делать delete и соответственно вакуум (просто как идея, я ж
    > хз что у него за данные и за модель)

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

     
     
  • 8.151, пох (?), 22:04, 22/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    если мы правильно угадали его проблему что это именно из-за особенностей стора,... текст свёрнут, показать
     
     
  • 9.156, Аноним (27), 11:41, 23/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Настройка стоимости операции для авто вакуума сделает тоже самое, только скрипт... текст свёрнут, показать
     
  • 2.129, Мудила (?), 14:30, 21/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ладно, понял, что осмысленно диалога "DBA с двадцатилетним стажем" не выйдет.
    Просто накрутите
    -- autovacuum_vacuum_cost_limit в десять раз (больше 1000) поставьте;
    -- autovacuum_vacuum_cost_delay сделайте в районе 5--10.
    Если не помогло, то предварительно всё же стоило убедиться, что проблема именно в недостаточно частой "уборке" файла отношения. Потому что подобное поведение может быть следствием очень длительной транзакции, которая работает по данным, которые вы часто изменяете, а значит -- это ошибка вашей модели и её нужно корректировать. В общем, не тупите и читайте документацию.
     
     
  • 3.153, Цезий Родонович (?), 09:36, 23/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну нету там длинных транзакций, нету инсертов, делейтов, много коротких апдейтов, и это НЕ единственная таблица, другим тоже нужны ресурсы процессора, память, вакумы, и т.д.
    Вакуум на ней висит практически постоянно, и не успевает, блять 2000 строк уже 260MB, простенький запрос к этой таблице должен выполнятся мгновенно, а он задумывается
     
     
  • 4.154, Аноним (27), 11:31, 23/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Думаю, вы уже знаете, что в Слоне update-ов нет, а есть delete insert Как и все... большой текст свёрнут, показать
     
     
  • 5.157, Цезий Родонович (?), 14:40, 23/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    есть и много процессов, но разные строки, 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
    пусто
     
     
  • 6.158, Аноним (27), 15:32, 23/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Блокировки тут не причём.
    Зомби-транзакции поищите. Всё же, очень похоже на то, что транзакции не фиксируются или разграничены не так, как вы себе представляете. Поэтому задействованные ими кортежи и не подвергаются уборке.
    А vacuum full эти мёртвые кортежи убирает?
    Понимаете, если у вас много обновляющих данные процессов в одном отношении, то подобная картинка вполне себе типична. В том, что в результате дофига хранится исторических данных, нет ничего ужасного и необычного. Их будет тем больше, чем больше параллельных процессов, работающих с отношением: им же всем нужно получить состояние кортежей на момент начала каждой из транзакций. Другое дело, что шлака столько не должно оставаться.
     
  • 6.159, Аноним (27), 16:01, 23/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Вот, скажем, началась у вас транзакция Т1. Она длиться, условно, 10 единиц времени. Через десять единиц времени она фиксируется.
    T1 началась во время t1.
    T2 началась в t1 + 1.
    T3 : t1 + 2
    T4 : t1 + 3.
    Ну и т.д.
    Т2 хочет видеть состояние БД на момент t1 + 1. И, соответственно, те кортежи, которые T1 похерила, но не зафиксировала, вакуум удалять не может -- они нужны T2, T3... И так по цепочке. В результате если у вас много процессов которые производят большое кол-во обновлений по ключу, то исторических "хвост" нужно будет держать весьма значительный.
    На этом фоне замена обновление на вставку, а потом явное удаление устаревших событий, не кажется таким уж нелепым решением.
     
  • 6.160, Аноним (27), 16:05, 23/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А памяти у нас на серваке много? Значение maintenance_work_mem сколько выставлено? БД в кластере много?
     
     
  • 7.161, Цезий Родонович (?), 09:10, 26/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Короче, нашел, в этой же базе но, вообще не имеюшее к этой таблице никакого отношения, "чужое" приложение после select-а не делает коммит. но у него свои таблицы и к моей никогда не обращается!!!
     
     
  • 8.162, Forth (ok), 10:24, 26/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Чужое приложение научили делать commit Помогло ... текст свёрнут, показать
     
     
  • 9.163, Цезий Родонович (?), 16:42, 26/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Чужого разработчика надо пнуть, а потом чтобы обновилось на сотнях ПК, я рубал в... текст свёрнут, показать
     
     
  • 10.164, Forth (ok), 18:26, 26/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Если дело в одной БД происходит и даже в разных схемах - бывает просто имена сов... текст свёрнут, показать
     
  • 4.155, Аноним (27), 11:38, 23/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Не зря вас про уровень изоляции транзакции спрашивали. Если у вас много параллельных запросов на изменение, к тому же все они serializable, то что-то подобное может произойти. Если приложение работает через jdbc-драйвер нужно проверить какой режим изоляции для транзакций выбран.
     
  • 2.136, лютый джо__ (?), 07:11, 22/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >есть табличка статусов, 2000 строк, обновляются половина каждые 10 секунд

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

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

     
     
  • 3.147, Аноним (27), 17:52, 22/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Слон с этим тоже работает без проблем. Собственно, как раз это самое lazy persistence и происходит: блоки из буферов практически с файл и не успевают попадать большую часть времени. Там фактический I/O с диском получается вообще мизерный.
     

     ....большая нить свёрнута, показать (58)

  • 1.76, Аноним (78), 22:38, 19/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Уже в Debian, Mandriva и, как ни странно, Termux:

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

     
  • 1.91, Andrew (??), 11:20, 20/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Переводчика на мыло! Зачем так переводить, что смысл кардинально меняется?

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

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

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

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

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

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

     
     
  • 2.104, Мудила (?), 14:43, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ваш вариант, по-моему, не лучше.
     
     
  • 3.123, Andrew (??), 22:34, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Мой вариант, простите, чего именно? Я, кажется, не предлагал альтернативных вариантов перевода, а лишь указал на ошибки в оригинальном переводе из новости...
     

  • 1.101, Аноним (100), 13:54, 20/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    CockroachDB через пару лет отправит на свалку этого динозавра.
    Из Postgresql уже песок сыпется
     
     
  • 2.102, Цезий Родонович (?), 14:16, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    https://opennet.ru/opennews/art.shtml?num=46529

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

    Вы об этом?

     
     
  • 3.122, Анонимно (?), 21:14, 20/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да, то было в первой версии.
    Прикинь, база маскируется под PostgreSQL, а ведет себя как распределенная, строго консистентная база данных.
    Маскируется она полностью, реализуя протокол PostgreSQL.
    Запускаешь 1 бинарник и у тебя база с мониторингом, которой приятно пользоваться.
     
     
  • 4.132, пох (?), 19:49, 21/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Да, то было в первой версии.

    а сейчас что?

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

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

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

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

     
     
  • 5.152, KonstantinB (ok), 04:46, 23/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Протокол постгреса весьма приятен и хорошо задокументирован. Null terminated-строками только несколько злоупотребляют, но это не страшно.
     

  • 1.111, Аноним (111), 15:31, 20/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что значит "Обеспечена корректная маршрутизация операций"? Оно и раньше работало, вот только транзакции там не работали, это оно или о чём речь?
     
  • 1.124, Аноним (124), 02:28, 21/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Для венды так и не сканпеляли. :( Чё за расизм?
     
     
  • 2.126, Andrey Mitrofanov (?), 09:56, 21/10/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Для венды так и не сканпеляли. :( Чё за расизм?

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

     
  • 2.141, Аноним (141), 11:38, 22/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.enterprisedb.com/download-postgresql-binaries

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

     

  • 1.125, Ддд (?), 03:02, 21/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как была тормозной херней так и осталась
     
  • 1.140, Аноним (141), 11:37, 22/10/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Где бинарные сборки?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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