Comments 14

Таблицы в доке зря переиначили. С телефона искать глазами очень неудобно в новой версии.

Ради форматирования и перевода в др.форматы, уничтожили читабельность. Молодцы, нечего сказать. Лучше бы комменты реализовали в документации.

Комменты в документации — это один из столпов, на которых стоит невероятная популярность PHP, кстати. Странно, что еще не все их делают.

Вряд ли комментарии сыграли в этом хоть какую-то роль. Когда PHP появился, у него был самый низкий порог входа: на всех других языках программирования требовалось изучать какие-то интерфейсы типа CGI, часто писать самостоятельно значительную часть обработки HTTP запросов и генерации ответов, тогда как в PHP ничего этого делать не надо было. Объективно, сложность написания простейшего скрипта на PHP была на порядки меньше, чем на любом другом языке.


Потом другие языки несколько догнали в плане лёгкости, появились различные фреймворки и упростилась процедура подключения приложения к веб-серверу. Но до сих пор это требует всё же несколько более усилий, чем просто забросить файл в почти любое место на веб-сервере. Пускай, это будет адская мешанина HTML и PHP, в которой через год уже не разобраться, но это не имеет значения для человека, который вообще не хочет читать документацию.


Мне сложно понять зачем нужны комментарии в документации. Что такого можно написать в комментариях к CREATE TABLE или SELECT, ради чего стоило бы в них рыться?

Возможно комментарии в документации реализованы не лучшим образом, но они есть. Для всех поддерживаемых версий (сейчас это с 9.5 по 12) внизу любой страницы документации есть раздел Submit correction. Заполняете форму и замечание после модерации приходит в список рассылки pgsql-docs. Там замечание обязательно рассматривают и если решат, что нужно внести изменения — вносят.
Да, списки рассылки не самый современный инструмент совместной работы, но проект postgresql пользуется именно им.
На мой взгляд и прежний вариант был далек от идеала. По крайней мере, когда я первый раз увидел форматирование функций в виде таблиц мне это показалось очень неудобным. Потом привык.

Нынешний вариант не выглядит явным улучшением. Да, проще конвертировать в PDF, но к читаемости вопросы есть. Попробуем с этим поработать.

А вообще приятно, что несколько первых комментариев именно по документации. Это к извечной шутке о том, «кто её читать будет». Читают, и это здорово!
Еще как читаем. От качества документации напрямую зависит популярность проекта, у PG она на высоком уровне. Но глядя на изменения — таблица — это четкое структурирование, что, зачем, куда, пример. А новинка, 10х по времени на понимание где якорь. Про комменты: в основном люди туда пишут примеры. Смотрите тот же PHP, MYSQL, Python. И примеры это очень важно. Накопление базы вменяемых примеров — это годы… И желательно пропустить через рецензирование. Текущая схема «аля комментирования» от слова — не работоспособна (для масс).
Согласен, база примеров (именно вменяемых) была бы очень полезна.

Выпилят примерно никогда. Тенденция такая, что стандартный heap останется универсальным движком, а альтернативы будут целиться в узкие области применения, где у них есть шансы показать лучший результат.
Конкретно насчет undo — это надо следить за успехами https://github.com/EnterpriseDB/zheap

Для производительности полезен коммит 56788d2156 (выделение блоков группой для параллельных запросов) и стоило бы сказать, что убрали PGXACT (серия патчей snapshot scalability, в частности 73487a60fc).
Также изменили системные лимиты для wraparound-а в cd5e82256d.

Виктор, спасибо!

Кроме коммита 56788d2156 (в статье он называется «Оптимизация ввода-вывода для параллельного последовательного сканирования»), для производительности параллельных запросов еще интересен коммит cdc7169 (про Gather). На моих простых тестах на ноутбуке я получал стабильно 12% ускорение против 13beta2 на запросе с группировкой. Правда, выносить результаты таких «детских» экспериментов в статью не стал. А в комментариях, думаю, можно поделиться.

Что касается коммитов о PGXACT и wraparound, то они случились уже в августе и формально под июльский коммитфест не попадают. А вот в следующей статье о сентябрьском коммитфесте будет рассмотрено всё принятое с 01.08 по 30.09 и они там будут.

Да, теперь увидел. Я искал по хэшу коммита, но он у вас обрезан, поэтому подумал что нет.
Спасибо!

Полное значения хеша слишком много места занимает, поэтому решил сократить. А для однозначной идентификации коммита вроде хватило.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
www.postgrespro.ru
Employees
51–100 employees
Registered

Habr blog