Если бы Дарт Вейдер существовал и решил бы сделать с Землёй то же, что он сделал с Алдерааном, все потеряли бы данные.
Мне нравится эта цитата Роберта Хааса, потому что это отрезвляющая реальность, которая нужна всем нам. В мире баз данных нам постоянно продают мечту о «пяти девятках» (99,999% времени доступности) и «нулевой потере данных» (RPO=0). Мы тратим месяцы на построение сложных кластеров, чтобы достичь этого.
Давайте будем честными: это сказки. Красивые для воображения, но они не существуют в рабочей среде. Если планетарная лазерная пушка — или даже просто серьёзный сетевой обрыв — поразит ваш дата-центр, ваши «гарантии» исчезнут.
Моя цель сегодня — не помочь вам поверить в сказки. Моя цель — помочь вам построить архитектуру, которая действительно работает.
Индексы существуют для ускорения доступа к данным. Они позволяют PostgreSQL избегать полного просмотра таблицы, значительно сокращая время выполнения запросов для рабочих нагрузок с интенсивным чтением.
Из реального производственного опыта мы наблюдали, что хорошо спроектированные, целевые индексы могут улучшить производительность запросов в 5 и более раз, особенно на больших транзакционных таблицах.
Однако индексы не являются бесплатными.
И в этой статье мы обсудим, какие проблемы могут вызывать неиспользуемые индексы и как удалить их из производственных систем с планом отката, безопасно.
Работа над RegreSQL заставила меня уделить много внимания буферам. Если вы иногда работаете с PostgreSQL, то наверняка слышали о настройке shared_buffers и следовали старому доброму совету выставить его на уровне 1/4 от доступной оперативной памяти. Но после того как мы немного слишком увлеклись этой темой в недавнем выпуске Postgres FM, меня спросили, что к чему.
Буферы — одна из тех тем, которую легко забыть. И хотя они являются фундаментальным блоком архитектуры производительности PostgreSQL, большинство из нас воспринимает их как чёрный ящик. Эта статья попытается это изменить.
Планировщик запросов PostgreSQL - это сложный инженерный механизм, обычно принимающий блестящие решения относительно того, как выполнять ваши запросы. Однако в сложных сценариях или при необычных распределениях данных вы можете знать лучший способ. Именно в таких ситуациях на помощь приходит pg_hint_plan - мощное расширение, которое позволяет вам руководить, или "советовать", планировщиком для выбора специфичного пути выполнения.
Regex является мощным средством обнаружения структуры внутри беспорядочных строк. PostgreSQL использует тут первоклассные функции регулярных выражений, включая REGEXP_MATCH для сопоставления и извлечения шаблонов.
Если вам когда-либо требовалось извлечь номер телефона из текста, проверить адрес электронной почты или захватить поименованный фрагмент строки, REGEXP_MATCH поможет вам сделать это за один шаг SQL.
