Предоставление доступа к вашей базе данных 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.
Продолжить чтение "Зачем использовать составной индекс в SQL Server"
file_copy_method — это перечисление из двух значений с совершенно невероятной отдачей. Одна из его настроек позволяет копировать базу данных примерно за долю секунды, независимо от того, имеет ли база данных размер один гигабайт или один терабайт. Другая — это способ, которым PostgreSQL всегда это делал. Перечисление является новым в PostgreSQL 18, и интересное значение — clone.
При обновлении между основными версиями PostgreSQL есть несколько способов. Дамп и восстановление (dump/restore) — самый простой с точки зрения понимания, но время простоя растёт прямо пропорционально размеру базы данных, поэтому для всего, что больше нескольких терабайт, этот вариант не подходит. Логическая репликация позволяет добиться почти нулевого времени простоя, но она работает только начиная с PostgreSQL 10; если ваш исходный кластер работает на версии ниже 10, этот путь в нативном виде недоступен. Остаётся pg_upgrade — инструмент, поддерживаемый сообществом для обновления основных версий «на месте». С флагом –link он создаёт жёсткие ссылки вместо копирования файлов данных, поэтому сам шаг обновления остаётся быстрым, независимо от размера базы данных.
Эта статья основан на обновлении с версии 9.6 до 17 на Ubuntu с использованием pg_upgrade. Я проведу вас через каждый этап, отмечу моменты, которые застают людей врасплох, и поделюсь проверочными запросами, которые мы выполняем после завершения обновления.
extra_float_digits — это настройка, чья задача изменилась под ней. На протяжении большей части истории PostgreSQL она принуждала к выбору между выводом чисел с плавающей точкой, который был удобен для чтения, и выводом, который был абсолютно точным, и нельзя было иметь и то, и другое. Начиная с PostgreSQL 12 вам больше не нужно выбирать, поэтому параметр, к которому вы, возможно, привыкли прибегать, теперь вам редко понадобится.
PostgreSQL уже записывает PID-файл. Каждый раз при запуске postmaster он помещает postmaster.pid в каталог данных и удаляет его при чистом завершении работы. Этот файл является блокировкой, которая предотвращает запуск второго postmaster с тем же каталогом данных, и содержит восемь строк с деталями работающего экземпляра: PID, каталог данных, время запуска, порт, каталог сокетов и так далее. external_pid_file не заменяет его. Он просит postmaster записать второй, гораздо меньший файл в другом месте.
На протяжении всей истории PostgreSQL до настоящего момента расширение должно было находиться ровно в одном месте. CREATE EXTENSION foo читал foo.control из встроенного каталога расширений, на который указывает pg_config --sharedir, и нигде больше не искал. Если вы хотели, чтобы расширение было доступно, его файлы должны были находиться в этом каталоге, что на практике означало установку от root в системное дерево или встраивание в образ. extension_control_path, новый в PostgreSQL 18, отменяет это допущение.
Когда люди говорят, что Python медленный, они обычно обвиняют язык.
В действительности это часто зависит от того, как мы пишем код.
Python является выразительным, читабельным и мощным. Но небольшие ошибки в структуре и обработке данных могут незаметно влиять на производительность...особенно в серверных системах или приложениях с большим объемом данных.