На просторах интернета не нашел единого рецепта по установке и настройке такого, довольно нестандартного сервера. Решил написать свой рецепт.
Принцип работы следующий:
Статические данные (файлы) отдает Nginx, а динамикой занимается Apache.Читать полностью »
Для сбора и удобного просмотра данных о том, как работает PostgreSQL (общая производительность сервера, самые медленные запросы, самые частые запросы) мы долгое время использовали отличную утилиту POWA. Однако, это решение было далеко не идеальным и нам удалось найти более удачный вариант, к тому же полностью интегрированный с нашей основной системой мониторинга.
Около месяца назад мои коллеги из DBA-команды приняли участие в живом митапе на youtube-канале #RuPostgres Live, где отвечали на вопросы Николая Самохвалова и зрителей, которые присылали их в форму и подключились к трансляции. Получилась интересная и содержательная беседа про PostgreSQL, опыт работы с разными версиями и задачами. Поэтому мы решили сделать текстовую расшифровку этой встречи, обогатив её полезными ссылками. В комментариях задавайте вопросы, если они возникнут — постараемся на них ответить!
Привет! DataGrip замыкает цепочку релизов наших IDE, хотя вы уже могли попробовать то, о чём я расскажу, в других продуктах: поддержка баз данных есть во всех наших IDE, кроме WebStorm (потому что он дешевле), CLion и AppCode (потому что не просят).
13 ноября на площадке Райффайзенбанка, прошел очередной PostgreSQL MeetUp. О том, как это было, что обсуждали и какие вопросы были самыми интересными, читайте под катом.
Мы уже рассмотрели механизм индексирования PostgreSQL, интерфейс методов доступа и все основные методы доступа, как то: хеш-индексы, B-деревья, GiST, SP-GiST и GIN. А в этой части посмотрим на превращение джина в ром.
Хоть авторы и утверждают, что джин — могущественный дух, но тема напитков все-таки победила: GIN следующего поколения назвали RUM.
Этот метод доступа развивает идею, заложенную в GIN, и позволяет выполнять полнотекстовый поиск еще быстрее. Это единственный метод в этой серии статей, который не входит в стандартную поставку PostgreSQL и является сторонним расширением. Есть несколько вариантов его установки:
Какие ограничения индекса GIN позволяет преодолеть RUM?
Во-первых, тип данных tsvector, помимо самих лексем, содержит информацию об их позициях внутри документа. В GIN-индексе, как мы видели в прошлый раз, эта информация не сохраняются. Из-за этого операции фразового поиска, появившиеся в версии 9.6, обслуживается GIN-индексом неэффективно и вынуждены обращаться к исходным данным для перепроверки.
Во-вторых, поисковые системы обычно возвращают результаты в порядке релевантности (что бы это ни означало). Для этого можно пользоваться функциями ранжирования ts_rank и ts_rank_cd, но их приходится вычислять для каждой строки результата, что, конечно, медленно.
Метод доступа RUM в первом приближении можно рассматривать как GIN, в который добавлена позиционная информация, и который поддерживает выдачу результата в нужном порядке (аналогично тому, как GiST умеет выдавать ближайших соседей). Пойдем по порядку.
На очередном собеседовании меня спросили о недостатках модели данных EAV (Entity Attribute Value), я не нашёл что сказать, на мой взгляд это идеальный способ хранения произвольных данных. После короткого раздумья, я сказал что единственная проблема это невозможность построить индексы для выборок.
После собеседования я озадачился этим вопросом на несколько дней, пришёл к каким то выводам, для очистки совести чуть чуть погуглил. Нагуглил подтверждения своим мыслям, но этого мне было мало — захотелось реализации с подтверждением цифрами.
Если и вам интересно к каким выводам я пришёл и какой выигрыш от оптимизации можно получить, то добро пожаловать под кат.
Читать полностью »
PostgreSQL — отличнейшая БД, планировщик которой достаточно интеллектуален.
Однако в ряде случаев мощь интеллекта планировщика вырастает настолько, что он превращается в сверх-интеллект, ну и как всякий сверх-интеллект — объявляет войну своему создателю, а прежде всего начинает с войны с проектом в котором живет.
Образумливать взбунтовавшийся интеллект иногда очень сложно. Поделюсь недавней "находкой" в этой области.
Сегодняшняя статья несколько необычна. Как минимум по той причине, что вместо анализа одного проекта, будем искать ошибки сразу в трёх, а также посмотрим, где найдутся наиболее интересные баги. А самое интересное — мы выясним, кто молодец и пишет самый качественный код. Итак, на повестке дня — разбор ошибок в коде проектов Firebird, MySQL и PostgreSQL.
Читать полностью »
На Higload++ 2017 года в Сколково наша компания Postgres Professional снова провела викторину с традиционной раздачей ништяков, в качестве которых выступили билеты на февральский PgConf.Russia 2018.
В этой статье разбираются вопросы викторины.
Читать полностью »
