PostgreSQL 9.2 — официальный релиз

    Сегодня, 10 сентября 2012 года, официально вышел релиз PostgreSQL 9.2!

    Наконец-то завершился долгий период бета-тестирования, объявленный в мае сего года. Разработчики обещают еще большую производительность, масштабируемость и гибкость (performance, scalability and flexibility).

    Улучшенная производительность и масштабируемость


    Postgres теперь поддерживает 64-ядерные процессоры, и снижено, его Postgres'a, энергопотребление. Тут подозреваю, все понятно и без лишних отступлений.

    Реализован механизм index-only scan. Что за зверь такой? Дело в том, что индексы в Postgres не содержат информации о видимости записи. То есть, чтобы понять видима ли какая-то запись, серверу нужно обязательно прочитать реальный табличный кортеж (tuple). Бывает ситуация, что в индексе содержится информация об устаревшем кортеже. Понятно и коню, что доступ к сортированному индексу намного быстрее доступа к реальной таблице, данные которой могут быть размазаны как угодно. Вкратце, в версии 9.2 этот финт ушами возможен. Хотя в индексе по-прежнему нет информации про видимость записи, разработчики реализовали, так называемую, «карту видимости» (visibility map). Как утверждает math: «Visibility map была давно уже. В новом релизе ее сделали устойчивой к падениям сервера, соответственно гарантированно корректной.» Все это и многое другое детально описано в Wiki.

    Улучшена и отполирована Потоковая Репликация (Streaming Replication). За деталями прошу проследовать во всю ту же Wiki.

    Из сладкого. Появилась родная поддержка типа JSON. Веб-разработчики вне себя от радости и бросают в воздух чепчики. Сервер проверяет валидность входящих данные, подсказывает где ошибка, если есть, содержит полный букет функций для конвертации из/в JSON. Например, array_to_json и row_to_json — просто счастье для ленивых, коим я всенепременно являюсь.

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

    Во-первых, диапазоны могут быть как дискретными, так и непрерывными. К дискретным стоит отнести такие встроенные типы как int4range, int8range и date4range. К непрерывным соответственно numrange, tsrange, tstzrange (ts — timestamp, num — numeric).

    Во-вторых, диапазон может быть открытым… Помните, про квадратные и круглые скобочки? [1;1] — закрытый, а [1;1) — открытый справа и т.д.

    В-третьих, границей диапазона может быть «бесконечность», та которая ∞! Помните анекдот про первоклассника?
    - Пап, а как восьмерка пишется?
    - Бесконечность повернутая на π/2.


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

    Мериться будем?


    В официальном тексте приводятся такие сравнительные числа с прошлыми версиями:
    • До 350000 запросов на чтение в секунду (в 4 раза быстрее)
    • Index-only сканирование может дать прирост в скорости от 2 до 20 раз
    • До 14000 записей данных в секунду (в 5 раз быстрее)


    Не знаю, насколько стоит верить данным пузомеркам, ведь скорее всего результаты получены на синтетических замерах, но все же…

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 35

      0
      кластера так и нет… =(
        0
        Подробностей можно?
          +2
          PITR дело хорошее, но заставляет хлопотать при отказе мастера, причем хлопотать конкретно. хочется все же дождаться, когда будет настоящий кластер, что бы не думать о том, что же делать, когда нода упадет, а утром приехать, чайку попить и аккуратно и спокойно восстановить ноду в кластер.

          а сейчас одни костыли в виде pgpool или corosync и то до первой серьезной БД.
            0
            Так кластер или репликация?
            У нас в 9.1 с нативной синхронной репликацией master-slave вообще проблем нет, все само работает. Если уже совсем сломалось, то две команды в консоли все починят.
            • UFO just landed and posted this here
          0
          Postgres-XC не годится?
            0
            нет
          –4
          Новость хорошая, а манера преподнесения крайне раздражает.
            +6
            Ну, простите. Официальных и суровых текстов, полагаю, в сети найдется немало.
              +2
              И, да… :) «Обидеть художника может каждый» ©
                –1
                Волков бояться — в лес не ходить. А разбавлять сухой текст можно, просто не обязательно это делать в духе «Понятно и коню».
                  +1
                  То есть, в принципе, кроме коней остальное выдержано стилистически?
                    0
                    Да лан, все норм, вспоминается первый релиз винампа — там в «О программе» была надпись что-то вроде «Ура, оно таки работает!».
                    Человеческие отношение не заменим формализмом.
                +1
                А мне понравилось. Расписано подробно и с огоньком. На меня подействовало — уже скачал и пробую.
                +2
                Visibility map была давно уже. В новом релизе ее сделали устойчивой к падениям сервера, соответственно гарантированно корректной.
                  0
                  Спасибо. Обновил текст статьи.
                  +7
                  Забыли очень интересную фичу: нормализацию запросов — все (plannable) запросы приводятся к «нормальному» виду, т.к. что даже prepared и unprepared statements делающие одно и то же, лежат в кэше парсера одинакого:
                  select  *  from  words  
                  where word = 'test'
                  
                  SELECT * FROM words WHERE word= ?
                  

                  Оба эти запроса имеют одинаковое внутреннее представление.

                  Какой нормализованый вид имеет запрос можно увидеть через view статистики по запросам pg_stat_statements.
                  select * from pg_stat_statements where query like '%words%';
                  
                    0
                    Круто! Надо будет проверить…
                      +1
                      Кстати, я не знаю, как вы это делаете… По запрсоу «plannable queries pg_stat_statements» в верху выдачи этот пост. У меня не было шансов. ;) У мануала Постгреса тоже.
                        0
                        Вот тут читайте: wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.2#pg_stat_statements

                        Кстати, там же недалеко (http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.2#Performance_improvements) еще про одно очень важное (с моей точки зрения) улучшение:
                        Prepared statements used to be optimized once, without any knowledge of the parameters' values. With 9.2, the planner will use specific plans regarding to the parameters sent (the query will be planned at execution), except if the query is executed several times and the planner decides that the generic plan is not too much more expensive than the specific plans

                        Т.е. если раньше для prepared запросов (а это, читай, все запросы внутри процедур) использовался один план, т.к. постгрес просто не учитывал параметры, то теперь он будет пытаться это делать и строить для для одного запроса разные планы.
                          0
                          Да, улучшения стоили того, чтобы их описать. Не дошел ход, как говорится.
                      +1
                      Забыли про:
                      1. Новый тип индексов SP-GiST
                      2. Статистика для массивов
                      3. Ускорение создания GiST индексов
                      4. Ускорение поиска по GiST индексам для геометрических типов
                        0
                        Я понял. ГИСТ — наше всё. ;) Пролил свет только на то, что позволяла конъюнктура. Будем откровенны — ГИСТ не для обывателя. Я с диапазонами жутко рисковал, расхваливая направо и налево…
                          +1
                          Кстати, было бы круто, если бы вы описали именно эти нововведения отдельным постом. Я откровенно плаваю в этой теме, а потому не позволю себе такого. Но вы абсолютно правы, объем работы по SP-GiST был колоссальный (насколько мне позволяет моя закостенелость).

                          А если учитывать, что локомотивом выступает наш (я в Тамбове родился, мне можно ;) Саша Коротков, то такая публикация должна быть!
                          0
                          > Из сладкого. Появилась родная поддержка типа JSON. Веб-разработчики вне себя от радости и бросают в воздух чепчики.

                          А что вы с JSON в базе делаете? Можно пример из жизни?
                            +1
                            Удобно из базы получать уже готовый json, вместо того чтобы конвертировать в него на уровне приклада. Во многих случаях это упрощает создание REST- и тп. сервисов
                              +1
                              Удобно из базы получать уже готовый json, вместо того чтобы конвертировать в него на уровне приклада. Во многих случаях это упрощает создание REST- и тп. сервисов
                                0
                                Спасибо! А в базе как храните данные? В реляционном виде, в таблицах или тоже в виде JSON?
                                  0
                                  Спасибо! А в базе как храните данные? В реляционном виде, в таблицах или тоже в виде JSON?
                                    +1
                                    Хотя сейчас и в моде всевозможное NoSQL, для меня лично поддержка JSON важна именно для форматирования результатов запросов на данных, хранимых все таки в реляционном формате. Если хранить в JSON, как-то нужно будет все это хозяйство потом индексировать (без потери транзакционности и других прелестей традиционной БД) — тема для меня пока туманная…
                                      0
                                      Спасибо за подробный ответ!
                                +1
                                По поводу JSON

                                > содержит полный букет функций для конвертации из/в JSON

                                К сожалению, не соответствует действительности. Пока с JSON не очень сложилось, тип данных, добавленный в 9.2, планируется развивать в дальнейшем. Валидация + array_to_json + row_to_json — это всё, что собственно и есть. Т.е. хранить данные в JSON не очень полезно, т.к. искать по ним не получится. Зато можно отдавать сложноструктурированный результат запроса в JSON.
                                  0
                                  А можно Вас тоже спросить: зачем вам хранить JSON в базе? Я так понимаю, что вы документ в этом формате откуда-то получаете и совсем при получении не анализируете? Это верно или бывают другие варианты сценариев?
                                    +1
                                    Так обычно делают, когда набор свойств объекта заранее не известен. В реляционных базах, традиционно, используют EAV, но он не слишком удобен и тормозит. А в MongoDB и др. NoSQL базах как раз предусмотрен JSON. В постгресе для этих же целей есть hstore.
                                      0
                                      Спасибо! То есть назначение типа как у сериализации объекта?

                                Only users with full accounts can post comments. Log in, please.