Мы продолжаем серию интервью с разработчиками Postgres Professional, которые получили медали за вклад в ванильный PostgreSQL. Почему полезен даже не принятый сообществом патч и при чём здесь везение, сегодня расскажет Александр Пыхалов.
У Александра три или четыре медали за вклад в ванильный PostgreSQL, точное количество он не помнит. Да и зачем? Одну получил за изменения функциональности postgres_fdw, ещё одну — за исправление бага. А самую заметную медаль ему выдали за поддержку проталкивания полусоединений (semi-joins) на сторону удалённого сервера. Она позволяет полностью выполнять запросы вроде SELECT * FROM t1 WHERE a IN (SELECT a FROM t2 WHERE t1.b<t2.b) на удалённом сервере, если таблицы T1 и T2 расположены на одном сервере.
Большой успех и маленькие неудачи
С ванильным Postgres Александр работал давно, но контрибьютить начал только с приходом в Postgres Professional.
Среди его последних удач: патч, который приблизил работу SQL-функций к pgSQL-функциям, вошёл в 18-ю версию PostgreSQL. Дело в том, что раньше SQL-функции Postgres использовали только машинерию generic-планов и не обращали внимания на заданные параметры. В результате планы для секционированных таблиц получались не очень: секции не отсекались, так как параметры не были известны. Александр добавил в SQL-функции использование кастомных планов, которые обрабатываются в зависимости от заданных параметров, как это реализовано в pgSQL.
Идея понравилась лидеру сообщества Тому Лейну, который закоммитил код патча, переписав его больше чем наполовину. Александр ничуть не расстроился: «Главное — не авторство коммита, а то, что SQL-функции стали намного ближе к pgSQL-функциям».
Ещё ему удалось запушить в сообщество исправление багов, связанных с пуш-дауном foreign join в postgres_fdw.
А вот пуш-даун соединения функции с foreign-таблицей сообщество не приняло, несмотря на все усилия Александра и его коллеги Глеба Кашкина. Возможно, ребята не обработали пограничные случаи или не рассмотрели спорные моменты, но ведь, помимо контрибьютерских, у них были более важные рабочие задачи. Времени на всё не хватило, пришлось выбирать.
Случается, что предложенные патчи намертво застревают. Например, в сообществе очень ждали патч, который пробрасывает вычисления агрегатов над секционированной таблицей на сторону удалённого сервера. Александр с коллегами застряли на том, что нужно передавать внутреннее представление агрегата по сети, а оно было нестабильным — менялось от одной версии PostgreSQL к другой. Простая проверка версий Postgres сообщество не устроила, и большой патч завис. Позже за него брались японцы, но и они не довели дело до конца.
Отсюда мораль: время и терпение — лучшие друзья контрибьютора.
Решения небольших очевидных проблем, которые всех «достают», обычно доезжают до коммита за пару недель. Над теми же, что посложнее или не на виду, можно работать годами. И результат здесь не гарантирован. Например, Александр с коллегами подготовили большой патч — проброс стабильных выражений на удалённые foreign-серверы. Сообщество попросило его доработать, а потом в Shardman закрыли эту функциональность другими средствами, и патч стал не интересен — он до сих пор висит.
Зачем контрибьютить в PostgreSQL
Контрибьюторство — это возможность сохранять знания и навыки. Патчи достаточно сложны, и, чтобы сообщество приняло их, авторам нужно доказать пользу и потратить на это немало сил. Иногда в процессе обсуждения одного патча приходят идеи относительно других.
Александр Пыхалов
Разработчик в Postgres Professional
Отдавая изменение сообществу, мы уменьшаем затраты на поддержку этого кода: ведь если связанный код будет эволюционировать, наш код тоже поправят. Естественно, для этого изменение должно быть востребовано. Часто в процессе обсуждения изменения мы обнаруживаем ошибки или недочёты, которые изначально не были видны. Иногда во время ревью патч эволюционирует во что-то более полезное. Но все пожелания сообщества удовлетворить сложно. Критерий «для меня патч уже достаточно хорош» здесь не действует.
Ну и, конечно, приятно, когда твой код попадает в такой проект, как PostgreSQL.
Советы начинающим контрибьюторам
Чтобы контрибьютить в сообщество, нужно не только сильно этого хотеть, но и ответить для себя на вопрос, зачем оно вам надо.
Александр Пыхалов
Разработчик в Postgres Professional
Бывает страшно, что ревью моего кода будет слишком поверхностным и мёрж-реквест коллеги одобрят слишком быстро. Победить этот страх можно, если отправить код на обсуждение сообществу.
Вот пара случаев из моей практики:
Предложил асинхронный мёрж-аппенд — шевеление было, но затихло.
Предложил разработать способ ограничить объём памяти для postgres_fdw (сейчас он может съесть неограниченное количество памяти). Переписка шла, но результата не было.
Даже несмотря на то, что обсуждения в обоих случаях не привели к результату, обратная связь оказалась полезной.
Как помочь патчу появиться в продукте?
Самое главное — понятно объясняйте людям, зачем нужен ваш патч, покажите его важность. Для этого чётко сформулируйте решаемую проблему и приведите примеры использования патча. С исправлением ошибок обычно проще, а вот новую функциональность надо хорошо обосновать.
Даже востребованную функциональность можно обсуждать годами. Почему? Например, вы не учли краевые случаи, и сообщество захочет получить более качественный или обобщённый код.
Второй фактор — удача. Потенциальный ревьювер может просто не заметить ваше сообщение. А может и заметить, тогда ваш звёздный час будет не за горами!
Удачи мы пожелаем всем, кто сомневается, надо ли начинать контрибьютить. Вперёд!