Вы построили индекс и протестировали запрос в SSMS. Index seek. Идеально. Вы пошли домой.
Между тем ваше приложение сканировало каждую строку в этой таблице, начиная со дня его запуска.
Это CONVERT_IMPLICIT - один из наиболее скрытых убийц производительности в SQL Server. Никаких ошибок. Никаких предупреждений в журнале приложения. Запрос возвращает правильные результаты, а ваш индекс отлично структурирован, но оптимизатор его не использует, поскольку тип данных, приходящих из приложения, не соответствует типу данных столбца - и SQL Server должен преобразовывать каждую строку, прежде чем он сможет выполнить сравнение.
Предоставление доступа к вашей базе данных PostgreSQL внешней команде — это решение, которое заслуживает некоторого обдумывания. Самый простой вариант — передать учётную запись суперпользователя, но это редко бывает правильным. Лучший подход — создать выделенную роль только с теми привилегиями, которые им действительно нужны, и это займёт всего несколько минут.
За эти годы я был по обе стороны этого разговора. Я был внешним администратором, которого подключали к базе данных клиента, и я был внутренним инженером, решающим, какой доступ предоставить. Шаблон, который я собираюсь вам показать, — это тот, к которому я бы прибег в любой из этих ситуаций: специально созданная, не-суперпользовательская роль, которая даёт внешней команде ровно то, что им нужно для реальной работы, и ничего лишнего.
fsync — это логический параметр, по умолчанию включён, его контекст — sighup, поэтому его можно изменить перезагрузкой конфигурации без перезапуска. Это также самая опасная настройка в postgresql.conf. Большинство параметров из этой серии при неправильной установке стоят вам плохого плана или некоторой потраченной впустую памяти. Этот же параметр при неправильной установке стоит вам кластера.
Если вы пришли из SQL Server (как в моём случае), индексы PostgreSQL могут показаться сначала знакомыми — существуют B-tree индексы, составные индексы, покрывающие индексы. А затем вы сталкиваетесь с запросами вроде:
WHERE payload @> '{"type":"payment","status":"failed"}'
или:
WHERE tsv @@ plainto_tsquery('postgresql')
В этот момент большинство разработчиков SQL Server задают два вопроса:
Что это за операторы?
Почему для этого PostgreSQL требуется совершенно другой тип индекса?
Почти никто не использует форму запроса, которой управляет этот параметр:
SELECT * FROM x, y, (SELECT * FROM a, b, c WHERE something) AS ss
WHERE somethingelse;
Но вы постоянно создаёте её, не желая того. Ссылка на представление, содержащее соединение, приводит к тому, что определение представления подставляется вместо ссылки, и планировщик видит именно это: подзапрос в вашем списке FROM. Вложенные представления, SQL, сгенерированный ORM, и всё, что построено из многократно используемых фрагментах запросов, попадает к планировщику в этой форме. from_collapse_limit решает, что планировщик будет с этим делать.
file_extend_method — это «запасной выход» в тушке регулятора настройки. Он существует для одной цели: позволить вам отключить оптимизацию PostgreSQL 16 на тех файловых системах, где эта оптимизация вела себя некорректно.
Запросы SQL могут выполняться долго, особенно на больших таблицах, при отсутствии надлежащего индексирования. Полное сканирование таблицы может быть затратной операцией, когда все, чего хочет пользователь, - это извлечь небольшое число строк на основе нескольких столбцов и фильтра WHERE. Как правильно проиндексировать наши таблицы для поддержки запросов по нескольким столбцам?
В этой статье я объясню, как использовать составной индекс для уменьшения стоимости тех запросов, которые используют фильтрацию по всем столбцам или по подмножеству столбцов. Уменьшение стоимости означает более быстрый запрос.
Не существует специальной настройки, требуемой для использования составных индексов. SQL Server поддерживает составные индексы. Для демонстрации функциональности я использую SQL Server 2022, исполняемый на Windows 10, с SQL Server Management Studio (SSMS) 2022.
Continue reading "Зачем использовать составной индекс в SQL Server"
file_copy_method — это перечисление из двух значений с совершенно невероятной отдачей. Одна из его настроек позволяет копировать базу данных примерно за долю секунды, независимо от того, имеет ли база данных размер один гигабайт или один терабайт. Другая — это способ, которым PostgreSQL всегда это делал. Перечисление является новым в PostgreSQL 18, и интересное значение — clone.
