Как стать автором
Обновить

Комментарии 8

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

То что он оказался быстрее, выяснили только сейчас. А про операторы ~>=~ и ~<~ благодаря которым они работает быстрее, до сих пор ничего не известно. В то же время в ChangeLog было заявлено, что starts_with() и индекс SP Gist гораздо эффективнее, чем LIKE и btree. Так что ваше утверждение, что "все знают" уже не верно. И в будущем может быть неверно. Вот если устроюсь в Postgres Pro, может перепишу starts_with(). :)
Как появляются "упоминания в документации", это не так работает. :) Если смотреть документацию на сайте, внизу есть форма отправить ваши предложения и замечания. Их реально читают, правда не всегда реагируют. Так что документация к PostgreSQL настолько хороша (искренне, я не видел тех.документации лучше), потому что это результат коллективного труда и с фидбэком от читателей.

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

11 версия вышла в 2018м году. т.е. 6 лет назад. :) Вы неправильно себе представляете процесс разработки. Разработкой занимается не одна могущественная корпорация со строгими корпоративными стандартами качества. Это Open Source, в котором участвуют как несколько корпораций, так и обычные любители. Так что всё что вы считаете обязательным, совсем не обязательно. Что-нибудь сделать и забыть задокументировать так это вообще обычное дело. Но работа ведётся и каждый может внести свой вклад. И может быть не совсем прямым путём, но в целом PostgreSQL движется в лучшую сторону.

Как ни странно в корпоративной разработке забыть что-то задокументировать гораздо проще. И стандарты качества PosgreSQL выше, чем у подавляющего количества ПО в принципе. Данная фича не просто была залита каким то разработчиком сразу в мастер и забыла, нет, она прошла несколько ревью и была включена в релиз.

Так я ничего не говорил плохого про код или функционал. А вот документация иногда несовершенна, все же программистам больше нравится писать код, а не обычный текст. Нравилось бы писать текст, стали бы писателями. Но её исправляют, если предложить как.

Загадочные ~>=~ и ~<~. В документации, в разделе посвященным
текстовым операторам, они отсутствуют. Я пытался гуглить, по ним вообще
нет никакой информации. Знаю только, что еще существуют операторы
~<=~ и ~>~. И все они работают с текстом таинственным образом.

Там ничего таинственного, эти операторы сравнивают строки посимвольно, без учета правил сортировки (collation). В доке их, действительно, почему-то нет. Они входят в классы операторов *_pattern_ops, про которые мимоходом сказано в https://postgrespro.ru/docs/postgresql/16/indexes-opclass#INDEXES-OPCLASS. Видимо, считается, что этого и достаточно.

Именно эту ссылку я и привел в своей статье. Про сами операторы там ничего. А это и означает, что они таинственные. Ясность вы внесли, но не совсем понятно, чем эти операторы лучше/хуже, чем обычные, но с COLLATION "'C".
Нет, не достаточно. Я читал ваши статьи про индексы в PostgreSQL, очень хорошие. Так что не останавливайтесь. :)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории