Особое внимание в статье уделяется таким фундаментальным функциям, как инфраструктура асинхронного ввода-вывода и поддержка Oauth 2.0, оптимизации производительности, например, пропуску сканирования btree, а также долгожданным функциям, например, встроенной поддержке UUIDv7.
Но при свыше 3000 вкладах в релиз имеется множество других изменений помимо упомянутых, о которых вы можете захотеть узнать. Мы поставили себе задачу осветить как можно больше изменений и в итоге рассмотрели около 30 функций в этой длинной записи блога (почти 5000 слов).
Булевы значения просты и рациональны, но они плохо масштабируются, когда ваша модель данных эволюционирует. Целые числа могу элегантно обрабатывать множество состояний, уменьшая сложность схемы.
При проектировании базы данных разработчики часто сталкиваются с выбором казалось бы простого решения: следует ли использовать булевы значения или целые для представления поля? Хотя на первый взгляд разница может показаться тривиальной, выбор может оказать существенное влияние на хранилище, поддержку и масштабируемость. Давайте исследуем "за" и "против" каждого подхода, сосредоточив внимание на размере хранилища, накладных операционных расходах и обслуживании в долгосрочной перспективе. Continue reading "Булевы значения и целые числа в базах данных: понимание компромиссов"
Строки не просто "сидят" в таблице в PostgreSQL. Они живут внутри страниц, перемещаются при обновлении и всякий раз получают новые "адреса" (CTID). Давайте разберемся подробнее и посмотрим, как это работает на самом деле.
1. Куча: Движок хранилища PostgreSQL
Когда вы создаете таблицу в PostgreSQL, она хранится как куча.
Куча - это просто неупорядоченная коллекция строк (кортежей). В отличие от некоторых баз данных, PostgreSQL автоматически не сохраняет строки в неком отсортированном порядке или по первичному ключу. Вместо этого она просто добавляет их на доступное пространство внутри страниц (блоков фиксированного размера 8Кб на диске).
Вы строите новую таблицу или добавляете столбец, и вы хотите знать, какой тип данных использовать: VARCHAR или NVARCHAR?
Если вам необходимо хранить данные Unicode, выбор сделан за вас: NVARCHAR говорит, что это буду я.
Но если вы не уверены, то можете подумать: "Я должен использовать VARCHAR, поскольку он занимает вдвое меньше места". Я это знаю, потому что чувствовал то же самое, но множество комментаторов указали мне на это, когда я опубликовал ответ в «Office Hours» о том, что по умолчанию я использую VARCHAR. Один за другим разработчики говорили мне, что я неправ и что в 2025 пришло время вместо этого по умолчанию использовать NVARCHAR. Давайте проведем эксперимент!
Чтобы выяснить это, давайте возьмем большую базу данных Stack Overflow и создадим две копии таблицы Users. Я использую здесь таблицу Users, чтобы сделать демонстрацию краткой и понятной, поскольку у меня нет возможности целый день загружать гигабайты данных (и перезагружаться, как вы сейчас увидите). Мы просто собираемся сфокусироваться на строковых столбцах, поэтому я создал одну с типами VARCHAR, а другую - с NVARCHAR. Затем для простоты мы загрузим только те данные, которые являются чисто VARCHAR (потому что некоторые чудаки могли добавить какие-нибудь необычные данные Unicode в столбец AboutMe). Continue reading "Что использовать: VARCHAR или NVARCHAR?"
При модификации данных в базе данных SQL соответствующие индексы тоже изменяются. Эти изменения приводят к фрагментации индексов. Фрагментация означает, что логический порядок данных на страницах индекса не соответствует физическому порядку. Во фрагментированных индексах информация не располагается логически, что делает операции извлечения данных из индекса более затратными по времени, это приводит к проблемам производительности запросов. Таким образом, фрагментацию индексов следует периодически устранять для поддержания высокой производительности. Операции перестройки и реорганизации индекса как раз направлены на дефрагментацию индексов.
В данной статье мы рассмотрим то, что является общим и различным в этих операциях. Прежде чем начать, мы объясним некоторые важные связанные с ними понятия. В частности, ту информацию, которая стоит за коэффициентом заполнения и статистикой, т.к. эти понятия упоминаются при обсуждении операций по перестроению и реорганизации индекса.
В этом релизе чуть ниже от таких основных функций, как асинхронный ввод-вывод и поддержка UUIDv7, мы видим это небольшое приятное улучшение:
"В этом релизе добавлены возможности доступа как к предыдущим (OLD), так и к текущим (NEW) значениям в предложении RETURNING для команд INSERT, UPDATE, DELETE and MERGE."
Это не такая уж крутая вещь, как асинхронный ввод-вывод, но одна из тех небольших функций, которые неоценимы в определенных ситуациях.
Раздувание индексов в PostgreSQL может вызывать проблемы, но его легко пропустить.
Я уже писала о том, как проблемы с вакуумированием могут помешать PostgreSQL использовать покрывающие индексы, и раздувание индексов — одна из причин, из-за которой вакууму приходится тяжело.
Эта статья рассказывает о том, что вам нужно знать о раздувании индексов: как его обнаружить и как исправить.
Все мы сталкивались с необходимостью изменить тип данных столбца в таблице. К сожалению, в PostgreSQL вы не можете сделать это за один шаг, если столбец используется в представлении. В этой статье мы опишем действия, необходимые для изменения типа данных столбца в таблице PostgreSQL.
В PostgreSQL, если столбец таблицы имеет зависимости, т.е. используется в представлении, вы получите ошибку, если попытаетесь изменить тип данных или всего лишь длину. Здесь мы увидим способ обойти это ограничение и заскриптовать все зависимости столбца/таблицы.
Поведение PostgreSQL
Чтобы объяснить поведение PostgreSQL, давайте выполним небольшой тест, используя тестовую базу данных Chinook, которую можно свободно загрузить с GitHub для различных СУБД. Это имитация магазина цифровых медиа с образцами данных. Все, что вам нужно сделать, - это загрузить требуемую версию, и вы получите все скрипты создания структуры и вставки данных.
