Вы просто хотите посмотреть ваши данные. Вы быстро набираете display(df) в ячейке notebook и жмете Выполнить. Это кажется совершенно безобидно - кроме того, это всего лишь предварительный просмотр вашего фрейма данных, не так ли?
Но через несколько мгновений ваш кластер начинает вращаться, ячейка работает намного дольше, чем ожидалось, и ваш браузер может даже заикаться.
Хотя display() является фантастическим инструментом для интерактивного исследования, но, если слишком сильно полагаться на него, он может незаметно задушить ваши задания Apache Spark. Давайте заглянем под капот, чтобы точно выяснить, что происходит, когда вы вызываете display(), почему все замедляется, и как простое переключение на show() может радикально улучшить вашу производительность. Продолжить чтение "Любопытный случай с display(df)"
escape_string_warning включён по умолчанию уже около двадцати лет, и на современном PostgreSQL, настроенном обычным образом, он никогда не скажет вам ни слова. Это не неисправность. Условие, о котором он предупреждает, перестало быть поведением по умолчанию в 2011 году.
enable_tidscan — это параметр enable_*, который вы почти наверняка никогда не установите, и на этот раз это не предупреждение, а просто факт о том, как происходят сканирования TID. Вы не натыкаетесь на него случайно, как на последовательное сканирование или сортировку. Сканирование TID появляется только тогда, когда вы явно написали условие на ctid, поэтому тип плана, которым управляет этот параметр, появляется именно тогда, когда вы его запросили, и никак иначе.
(Для протокола: я за всю свою жизнь ни разу не видел узел tidscan.)
В статье о HOT-обновлениях в Postgres мы рассмотрели, как обрезка страниц (page pruning) очищает HOT-цепочки — элегантное сокращение, с помощью которого PostgreSQL освобождает место мёртвых кортежей во время обычных операций чтения. И всё это без ожидания фонового процесса. Но обрезка — это именно сокращение. Она работает только в пределах одной страницы и только для кортежей, обновлённых через HOT. Для всего остального (холодные обновления, затрагивающие индексированные столбцы, обычные DELETE, очистка записей индексов, регистрация в карте свободного пространства, обслуживание карты видимости) необходим VACUUM.
Эта статья не будет повторять то, что VACUUM делает с эксплуатационной точки зрения. Статья DELETEs are difficult охватывает настройку autovacuum, распределение рабочих процессов и эксплуатационную сторону очистки мёртвых кортежей. Здесь мы будем наблюдать за работой VACUUM побайтово. Мы сделаем снимок страницы до и после каждого этапа, отслеживая, что именно меняется в заголовке страницы, указателях строк, заголовках кортежей, карте свободного пространства и карте видимости. Инструменты всё те же: pageinspect, pg_visibility и pg_freespacemap.
Обращение к enable_sort = off, потому что в запросе есть медленная сортировка, обычно бьёт мимо цели. Когда сортировка медленная, это обычно происходит из-за того, что она сбрасывается на диск, что является проблемой work_mem. Если сортировки вообще не должно быть, исправление — это индекс. enable_sort не изменяет ни одного из этих факторов, и его отключение редко бывает тем, что вам действительно нужно.
enable_seqscan не отключает последовательные сканирования. Он не может этого сделать, и никогда не был для этого предназначен. В документации прямо сказано: последовательные сканирования невозможно полностью подавить, потому что иногда чтение всей таблицы является единственным способом ответить на запрос. На самом деле, значение off говорит планировщику избегать последовательного сканирования, только когда у него есть любая другая альтернатива. Это диагностическая инструкция, а не конфигурационная, и это различие — весь смысл данного параметра.
По умолчанию включён, контекст — пользовательский. Вы отключаете его в сессии, чтобы задать вопрос планировщику. Вы никогда не отключаете его в postgresql.conf, и мы объясним почему.
В одной из производственных баз данных PostgreSQL 16.8 нашего клиента в журнале начала появляться ошибка, похожая на ошибку памяти:
ERROR: invalid memory alloc request size
Ошибка сразу указывала на двух вероятных виновников:
Исчерпание памяти
Повреждение памяти
Как оказалось, ни то, ни другое не было причиной. Вместо этого мы столкнулись с известной ошибкой PostgreSQL, которая заперла процесс контрольной точки (checkpointer) в бесконечном цикле повторных попыток. Единственным способом восстановления была принудительная перезагрузка, за которой последовало длительное воспроизведение WAL во процессе аварийного восстановления.
Эта статья объясняет, что произошло, почему ручные контрольные точки не могли это исправить, и как обновление до минорной версии PostgreSQL окончательно решило проблему.
Вы редко являетесь единственным, кто пишет ваш SQL. Ваша ORM пишет часть его, ваши вложенные представления пишут ещё больше, и рано или поздно одно из них соединяет таблицу саму с собой по её собственному первичному ключу. Это соединение возвращает ровно те строки, с которых началось. enable_self_join_elimination — это оптимизация PostgreSQL 18, которая замечает и удаляет такое соединение.
Недавно во время одной из миграций Oracle на PostgreSQL с корпоративным клиентом при разработке резервного модуля runbook мы оценивали шаги по выполнению сброса значения последовательности для соответствия исходному значению так, чтобы каждый новый запрос значения с использованием NextVal был новым и не приводил к сбою транзакций.
Это один из критических шагов любой миграции базы данных, т.к. в большинстве случаев последовательность LAST_VALUE не переносится в целевой объект неявно, а значения последовательности должны совпадать с источником, чтобы новая транзакция никогда не завершалась неудачей и приложение работало после переключения.
Мы использовали экспорт SEQUENCE_VALUES в ora2pg для генерации команд DDL, чтобы установить последние значения последовательностей.
enable_presorted_aggregate включён, он включён с момента появления в PostgreSQL 16, и самое полезное, что вы когда-либо сделаете с ним, — это отключите его ровно для одного запроса.
По умолчанию включён, контекст — пользовательский: может быть установлен для сессии, роли, базы данных или встроен в одну транзакцию. Последний вариант — это и есть вся рекомендация, так что запомните его.
«Собрат» параметра enable_partitionwise_aggregate, и он разделяет его определяющую черту: по умолчанию он выключен, и по той же причине. Поэтому, чтобы не повторять полностью аргументацию о том, почему он выключен по умолчанию, в этом посте рассматривается, что здесь отличается — механизм, преимущество, которого нет у версии для агрегации, и предусловие, достаточно строгое, чтобы быть главной причиной, по которой функция не срабатывает, когда люди её ожидают. По умолчанию выключен, контекст — пользовательский. Как и его «собрат», включение этого параметра — это реальное решение по настройке, а не диагностический зонд.
Один из действительно важных параметров секционирования, который стоит понимать, а не просто оставлять включённым, — потому что он выполняет свою работу в два разных момента, и разница между ними определяет, насколько он может помочь вашим запросам. По умолчанию включён, контекст пользовательский, и он относится к тому же семейству, что и enable_async_append: это диагностический инструмент, а не регулятор настройки. Это параметр, который позволяет PostgreSQL пропускать сканирование разделов, которые не могут содержать строки, нужные запросу.
Я являюсь фанатом последовательностей с тех пор, когда они появились в SQL Server 2012. До этого у разработчиков был выбор между столбцами IDENTITY и создания собственного механизма для таблиц.
Что такое последовательности в SQL Server?
Последовательности позволяют создавать привязанный к схеме объект, который не связан ни с какой конкретной таблицей.
Например, если у меня есть таблицы Sales.FlightBookings и Sales.VehicleBookings, и я хочу иметь общий BookingID, используемый как ключ для каждой таблицы. Если бы речь шла не только о BookingID, вы могли бы возразить, что существует проблема с нормализацией таблиц, но мы оставим это обсуждение на будущее.
Продолжить чтение "Как узнать последнее значение, используемое последовательностью в SQL Server"
Переключатель для параллельных запросов, уточняющий хэш-соединение из статьи про enable_hashjoin, и он требует точности, потому что «хэш-соединение, выполняемое параллельно» и «параллельное хэш-соединение» — это две действительно разные вещи. По умолчанию включён, контекст пользовательский, и он относится к тому же семейству, что и enable_async_append: это диагностический инструмент, а не регулятор настройки.
