С zheap понятно только то, что затихло. Конкретика и планы неизвестны.
А на merge посмотрим, может в 15 попадет.
Лично мне еще нравится патч schema variables. Эта штука, помимо прочего, даст возможность реализовать что-то вроде ораклового контекста, без чего полноценно использовать RLS сложно.
Поскольку с SQLite не работал, то и документацию не видел. А вот сейчас пошел и посмотрел. Но знакомства в несколько минут врядли достаточно, чтобы выносить мнение. Что-то понравилось (активное использование диаграмм), что-то не очень (почти нет примеров, что для функций, что для команд SQL). Допускаю, что плохо смотрел. Что значит допускаю? Так и есть.
Предположу, что Вам чего-то не хватает в документации PostgreSQL из того к чему привыкли в SQLite. Буду признателен если поделитесь.
Должен ли PostgreSQL поддерживать команды из других СУБД? Разработчики постгреса так не считают. Для совместимости с другими СУБД есть стандарт SQL. И вот этот стнадарт в постгресе стараются поддерживать очень хорошо. А в стандарте SQL для доступа к объектам системного каталога предусмаотрена информационная схема. Она поддерживается, можно писать запросы к представлению с именем tables.
То, что длинный текст запроса можно «обернуть» в представление или функцию с коротким именем Вы наверное и так знаете.
Кстати замечу, что приведенный Вами запрос к pg_tables не полностью соответствует тому, что выдает show tables. Например будут показаны таблицы, к которым у пользователя нет доступа.
List of relations
Schema | Name | Type | Owner
----------+----------------+-------+-------
bookings | aircrafts_data | table | pal
bookings | airports_data | table | pal
(2 rows)
2. Про hba.conf. Там есть возможность указать в файле групповую роль, тогда любой пользователь входящий в неё будет аутентифицироваться по этой строчке в hba. Таким образом в hba можно определить несколько видов аутентификации с групповыми ролями. Затем, при добавлении пользователя, редактировать hba не надо, надо только включить пользователя в нужную групповую роль.
Это если я правильно понял проблему.
Кроме коммита 56788d2156 (в статье он называется «Оптимизация ввода-вывода для параллельного последовательного сканирования»), для производительности параллельных запросов еще интересен коммит cdc7169 (про Gather). На моих простых тестах на ноутбуке я получал стабильно 12% ускорение против 13beta2 на запросе с группировкой. Правда, выносить результаты таких «детских» экспериментов в статью не стал. А в комментариях, думаю, можно поделиться.
Что касается коммитов о PGXACT и wraparound, то они случились уже в августе и формально под июльский коммитфест не попадают. А вот в следующей статье о сентябрьском коммитфесте будет рассмотрено всё принятое с 01.08 по 30.09 и они там будут.
Возможно комментарии в документации реализованы не лучшим образом, но они есть. Для всех поддерживаемых версий (сейчас это с 9.5 по 12) внизу любой страницы документации есть раздел Submit correction. Заполняете форму и замечание после модерации приходит в список рассылки pgsql-docs. Там замечание обязательно рассматривают и если решат, что нужно внести изменения — вносят.
Да, списки рассылки не самый современный инструмент совместной работы, но проект postgresql пользуется именно им.
На мой взгляд и прежний вариант был далек от идеала. По крайней мере, когда я первый раз увидел форматирование функций в виде таблиц мне это показалось очень неудобным. Потом привык.
Нынешний вариант не выглядит явным улучшением. Да, проще конвертировать в PDF, но к читаемости вопросы есть. Попробуем с этим поработать.
А вообще приятно, что несколько первых комментариев именно по документации. Это к извечной шутке о том, «кто её читать будет». Читают, и это здорово!
Разница связана с использованием в функции переменных типа double precision, не гарантирующего абсолютную точность. Если точность всё-таки требуется, следует использовать тип numeric.
А более точное значение числа pi можно получить увеличением количества итераций цикла. Однако для демонстрации ускорения вычислений в 13 версии вполне достаточно и текущего значения.
Будем считать, что это затишье перед ...
А у вас pg_variables в postgres pro используется или вы собрали для его для PostgreSQL?
А на merge посмотрим, может в 15 попадет.
Лично мне еще нравится патч schema variables. Эта штука, помимо прочего, даст возможность реализовать что-то вроде ораклового контекста, без чего полноценно использовать RLS сложно.
Предположу, что Вам чего-то не хватает в документации PostgreSQL из того к чему привыкли в SQLite. Буду признателен если поделитесь.
Должен ли PostgreSQL поддерживать команды из других СУБД? Разработчики постгреса так не считают. Для совместимости с другими СУБД есть стандарт SQL. И вот этот стнадарт в постгресе стараются поддерживать очень хорошо. А в стандарте SQL для доступа к объектам системного каталога предусмаотрена информационная схема. Она поддерживается, можно писать запросы к представлению с именем tables.
То, что длинный текст запроса можно «обернуть» в представление или функцию с коротким именем Вы наверное и так знаете.
Кстати замечу, что приведенный Вами запрос к pg_tables не полностью соответствует тому, что выдает show tables. Например будут показаны таблицы, к которым у пользователя нет доступа.
2. Про hba.conf. Там есть возможность указать в файле групповую роль, тогда любой пользователь входящий в неё будет аутентифицироваться по этой строчке в hba. Таким образом в hba можно определить несколько видов аутентификации с групповыми ролями. Затем, при добавлении пользователя, редактировать hba не надо, надо только включить пользователя в нужную групповую роль.
Это если я правильно понял проблему.
Кроме коммита 56788d2156 (в статье он называется «Оптимизация ввода-вывода для параллельного последовательного сканирования»), для производительности параллельных запросов еще интересен коммит cdc7169 (про Gather). На моих простых тестах на ноутбуке я получал стабильно 12% ускорение против 13beta2 на запросе с группировкой. Правда, выносить результаты таких «детских» экспериментов в статью не стал. А в комментариях, думаю, можно поделиться.
Что касается коммитов о PGXACT и wraparound, то они случились уже в августе и формально под июльский коммитфест не попадают. А вот в следующей статье о сентябрьском коммитфесте будет рассмотрено всё принятое с 01.08 по 30.09 и они там будут.
Действительно, вот коммит, где применили новое форматирование: 69bfaf2e1.
После заморозки кода еще в нескольких упомянутых в статье разработках появились изменения, вот здесь можно про них найти.
Да, списки рассылки не самый современный инструмент совместной работы, но проект postgresql пользуется именно им.
Нынешний вариант не выглядит явным улучшением. Да, проще конвертировать в PDF, но к читаемости вопросы есть. Попробуем с этим поработать.
А вообще приятно, что несколько первых комментариев именно по документации. Это к извечной шутке о том, «кто её читать будет». Читают, и это здорово!
А более точное значение числа pi можно получить увеличением количества итераций цикла. Однако для демонстрации ускорения вычислений в 13 версии вполне достаточно и текущего значения.