INSERT
INSERT — добавить строки в таблицу
Синтаксис
[ WITH [ RECURSIVE ]запрос_WITH
[, ...] ] INSERT INTOимя_таблицы
[ ASпсевдоним
] [ (имя_столбца
[, ...] ) ] [ OVERRIDING { SYSTEM | USER } VALUE ] { DEFAULT VALUES | VALUES ( {выражение
| DEFAULT } [, ...] ) [, ...] |query
} [ ON CONFLICT [объект_конфликта
]действие_при_конфликте
] [ RETURNING { * |выражение_результата
[ [ AS ]имя_результата
] } [, ...] ] Здесь допускаетсяобъект_конфликта
: ( {имя_столбца_индекса
| (выражение_индекса
) } [ COLLATEправило_сортировки
] [класс_операторов
] [, ...] ) [ WHEREпредикат_индекса
] ON CONSTRAINTимя_ограничения
идействие_при_конфликте
может быть следующим: DO NOTHING DO UPDATE SET {имя_столбца
= {выражение
| DEFAULT } | (имя_столбца
[, ...] ) = [ ROW ] ( {выражение
| DEFAULT } [, ...] ) | (имя_столбца
[, ...] ) = (вложенный_SELECT
) } [, ...] [ WHEREусловие
]
Описание
INSERT
добавляет строки в таблицу. Эта команда может добавить одну или несколько строк, сформированных выражениями значений, либо ноль или более строк, выданных дополнительным запросом.
Имена целевых столбцов могут перечисляться в любом порядке. Если список с именами столбцов отсутствует, по умолчанию целевыми столбцами становятся все столбцы заданной таблицы; либо первые N
из них, если только N
столбцов поступает от предложения VALUES
или запроса
. Значения, получаемые от предложения VALUES
или запроса
, связываются с явно или неявно определённым списком столбцов слева направо.
Все столбцы, не представленные в явном или неявном списке столбцов, получат значения по умолчанию, если для них заданы эти значения, либо NULL в противном случае.
Если выражение для любого столбца выдаёт другой тип данных, система попытается автоматически привести его к нужному.
Операция INSERT
с таблицами без уникальных индексов не блокируется параллельно выполняемыми операциями. В таблицах с уникальными индексами эта операция может блокироваться, если в параллельных сеансах выполняются действия, которые блокируют или изменяют строки, совпадающие с вставляемыми значениями в уникальном индексе; подробнее см. Раздел 58.5. Предложение ON CONFLICT
позволяет задать действие, заменяющее возникновение ошибки при нарушении ограничения уникальности или ограничения-исключения. (См. описание Предложение ON CONFLICT ниже.)
С необязательным предложением RETURNING
команда INSERT
вычислит и возвратит значения для каждой фактически добавленной строки (или изменённой, если применялось предложение ON CONFLICT DO UPDATE
). В основном это полезно для получения значений, присвоенных по умолчанию, например, последовательного номера записи. Однако в этом предложении можно задать любое выражение со столбцами таблицы. Список RETURNING
имеет тот же синтаксис, что и список результатов SELECT
. В результате будут возвращены те строки, которые были успешно вставлены или изменены. Например, если строка была заблокирована, но не изменена, из-за того, что условие
в предложении ON CONFLICT DO UPDATE ... WHERE
не удовлетворено, эта строка возвращена не будет.
Чтобы добавлять строки в таблицу, необходимо иметь право INSERT
для неё. Если присутствует предложение ON CONFLICT DO UPDATE
, также требуется иметь право UPDATE
для этой таблицы.
Если указывается список столбцов, достаточно иметь право INSERT
только для перечисленных столбцов. Аналогично, с предложением ON CONFLICT DO UPDATE
достаточно иметь право UPDATE
только для столбцов, которые будут изменены. Однако предложение ON CONFLICT DO UPDATE
также требует наличия права SELECT
для всех столбцов, значения которых считываются в выражениях ON CONFLICT DO UPDATE
или в условии
.
Для применения предложения RETURNING
требуется право SELECT
для всех столбцов, перечисленных в RETURNING
. Если для добавления строк применяется запрос
, для всех таблиц или столбцов, задействованных в этом запросе, разумеется, необходимо иметь право SELECT
.
Параметры
Добавление
В этом разделе рассматриваются параметры, применяемые только при добавлении новых строк. Параметры, применяемые исключительно с предложением ON CONFLICT
, описываются отдельно.
запрос_WITH
Предложение
WITH
позволяет задать один или несколько подзапросов, на которые затем можно ссылаться по имени в запросеINSERT
. Подробнее об этом см. Раздел 7.8 и SELECT.Заданный
запрос
(операторSELECT
) также может содержать предложениеWITH
. В этом случае взапросе
можно обращаться к обоимзапросам_WITH
, но второй будет иметь приоритет, так как он вложен ближе.имя_таблицы
Имя существующей таблицы (возможно, дополненное схемой).
псевдоним
Альтернативное имя, заменяющее
имя_таблицы
. Когда указывается этот псевдоним, он полностью скрывает реальное имя таблицы. Это особенно полезно, когда в предложенииON CONFLICT DO UPDATE
фигурирует таблица с именемexcluded
, так как без определения псевдонима это имя будет отдано специальной таблице, представляющей строку, предназначенную для добавления.имя_столбца
Имя столбца в таблице
имя_таблицы
. Это имя столбца при необходимости может быть дополнено именем вложенного поля или индексом в массиве. (Когда данные вставляются только в некоторые поля столбца составного типа, в другие поля записывается NULL.) Обращаясь к столбцу в предложенииON CONFLICT DO UPDATE
, включать имя таблицы в ссылку на целевой столбец не нужно. Например, записьINSERT INTO table_name ... ON CONFLICT DO UPDATE SET table_name.col = 1
некорректна (это согласуется с общим поведением командыUPDATE
).OVERRIDING SYSTEM VALUE
Если указывается это предложение, то значения, предоставляемые для столбцов идентификации, переопределяют значения, выдаваемые последовательностью по умолчанию.
Для столбца идентификации, определённого со свойством
GENERATED ALWAYS
, считается ошибкой присваивание явного значения (кроме DEFAULT) без указанияOVERRIDING SYSTEM VALUE
илиOVERRIDING USER VALUE
. (Для столбца идентификации, определённого со свойствомGENERATED BY DEFAULT
, указаниеOVERRIDING SYSTEM VALUE
соответствует обычному поведению и ни на что не влияет, но PostgreSQL допускает его как дополнение.)OVERRIDING USER VALUE
Если указывается это предложение, то значения, предоставляемые для столбцов идентификации, игнорируются и вместо них применяются значения, выдаваемые последовательностью по умолчанию.
Это предложение полезно, например, при копировании значений между таблицами. Команда
INSERT INTO tbl2 OVERRIDING USER VALUE SELECT * FROM tbl1
скопирует изtbl1
все столбцы, кроме столбцов идентификации вtbl2
, а значения столбцов идентификации вtbl2
будут сгенерированы последовательностями вtbl2
.DEFAULT VALUES
Все столбцы получат значения по умолчанию, как в случая явного указания
DEFAULT
для каждого столбца. (ПредложениеOVERRIDING
в этой форме не допускается.)выражение
Выражение или значение, которое будет присвоено соответствующему столбцу.
DEFAULT
Соответствующий столбец получит значение по умолчанию. Столбец идентификации получит новое значение, выданное связанной последовательностью. Для генерируемого столбца это указание допускается, но не меняет обычное поведение, то есть значение столбца вычисляется генерирующим выражением.
query
Запрос (оператор
SELECT
), который выдаст строки для добавления в таблицу. Его синтаксис описан в справке оператора SELECT.выражение_результата
Выражение, которое будет вычисляться и возвращаться командой
INSERT
после добавления или изменения каждой строки. В этом выражении можно использовать имена любых столбцов таблицыимя_таблицы
. Чтобы получить все столбцы, достаточно написать*
.имя_результата
Имя, назначаемое возвращаемому столбцу.
Предложение ON CONFLICT
Необязательное предложение ON CONFLICT
задаёт действие, заменяющее возникновение ошибки при нарушении ограничения уникальности или ограничения-исключения. Для каждой отдельной строки, предложенной для добавления, добавление либо выполняется успешно, либо, если нарушается решающее ограничение или индекс, задаваемые как объект_конфликта
, выполняется альтернативное действие_конфликта
. Вариант ON CONFLICT DO NOTHING
в качестве альтернативного действия просто отменяет добавление строки. Вариант ON CONFLICT DO UPDATE
изменяет существующую строку, вызвавшую конфликт со строкой, предложенной для добавления.
Задаваемый объект_конфликта
может выбирать уникальный индекс. Определение объекта, позволяющее выбрать индекс, включает один или несколько столбцов (их определяет имя_столбца_индекса
) и/или выражение_индекса
и необязательный предикат_индекса
. Все уникальные индексы в таблице имя_таблицы
, которые, без учёта порядка столбцов, содержат в точности столбцы/выражения, определяющие объект_конфликта
, выбираются как решающие индексы. Если указывается предикат_индекса
, он должен, в качестве дополнительного требования выбора, удовлетворять индексам. Заметьте, что это означает, что не частичный уникальный индекс (уникальный индекс без предиката) будет выбран (и будет использоваться в ON CONFLICT
), если такой индекс удовлетворяет всем остальным критериям. Если попытка выбрать индекс оказывается неудачной, выдаётся ошибка.
ON CONFLICT DO UPDATE
гарантирует атомарный результат команды INSERT
или UPDATE
; при отсутствии внешних ошибок гарантируется один из двух этих исходов, даже при большой параллельной активности. Эта операция также известна как UPSERT — «UPDATE или INSERT».
объект_конфликта
Определяет, для какого именно конфликта в
ON CONFLICT
будет предпринято альтернативное действие, устанавливая решающие индексы. Это указание позволяет осуществить выбор уникального индекса или явно задаёт имя ограничения. ДляON CONFLICT DO NOTHING
объект_конфликта
может не указываться; в этом случае игнорироваться будут все конфликты с любыми ограничениями (и уникальными индексами). ДляON CONFLICT DO UPDATE
объект_конфликта
должен указываться.действие_при_конфликте
Параметр
действие_при_конфликте
задаёт альтернативное действие в случае конфликта. Это может быть либоDO NOTHING
(не делать ничего), либо предложениеDO UPDATE
(произвести изменение), в котором указываются точные детали операцииUPDATE
, выполняемой в случае конфликта. ПредложенияSET
иWHERE
вON CONFLICT DO UPDATE
могут обращаться к существующей строке по имени таблицы (или псевдониму) или к строке, предлагаемой для добавления, используя специальную таблицуexcluded
. Для чтения столбцовexcluded
необходимо иметь правоSELECT
для соответствующих столбцов в целевой таблице.Заметьте, что эффект действий всех триггеров уровня строк
BEFORE INSERT
отражается в значенияхexcluded
, так как в результате этих действий строка может быть исключена из множества добавляемых.имя_столбца_индекса
Имя столбца в таблице
имя_таблицы
. Используется для выбора решающих индексов. Задаётся в форматеCREATE INDEX
. Чтобы запрос выполнился, для столбцаимя_столбца_индекса
требуется правоSELECT
.выражение_индекса
Подобно указанию
имя_столбца_индекса
, но применяется для выбора индекса по выражениям со столбцами таблицыимя_таблицы
, фигурирующим в определениях индексов (не по простым столбцам). Задаётся в форматеCREATE INDEX
. Для всех столбцов, к которым обращаетсявыражение_индекса
, необходимо иметь правоSELECT
.правило_сортировки
Когда задаётся, устанавливает, что соответствующие
имя_столбца_индекса
иливыражение_индекса
должны использовать определённый порядок сортировки, чтобы этот индекс мог быть выбран. Обычно это указание опускается, так как от правил сортировки чаще всего не зависит, произойдёт ли нарушение ограничений или нет. Задаётся в форматеCREATE INDEX
.класс_операторов
Когда задаётся, устанавливает, что соответствующие
имя_столбца_индекса
иливыражение_индекса
должны использовать определённый класс, чтобы индекс мог быть выбран. Обычно это указание опускается, потому что семантика равенства часто всё равно одна и та же в разных классах операторов типа, или потому что достаточно рассчитывать на то, что заданные уникальные индексы имеют адекватное определение равенства. Задаётся в форматеCREATE INDEX
.предикат_индекса
Используется для выбора частичных уникальных индексов. Выбраны могут быть любые индексы, удовлетворяющие предикату (при этом они могут не быть собственно частичными индексами). Задаётся в формате
CREATE INDEX
. Для всех столбцов, задействованных впредикате_индекса
, требуется правоSELECT
.имя_ограничения
Явно задаёт решающее ограничение по имени, что заменяет неявный выбор ограничения или индекса.
условие
Выражение, выдающее значение типа
boolean
. Изменены будут только те строки, для которых это выражение выдастtrue
, хотя при выборе действияON CONFLICT DO UPDATE
заблокируются все строки. Заметьте, чтоусловие
вычисляется в конце, после того как конфликт был признан претендующим на выполнение изменения.
Заметьте, что ограничения-исключения не могут быть решающими в ON CONFLICT DO UPDATE
. Во всех случаях в качестве решающих поддерживаются только неоткладываемые (NOT DEFERRABLE
) ограничения и уникальные индексы.
Команда INSERT
с предложением ON CONFLICT DO UPDATE
является «детерминированной». Это означает, что этой команде не разрешено воздействовать на любую существующую строку больше одного раза; в случае такой ситуации возникнет ошибка нарушения мощности множества. Строки, предлагаемые для добавления, не должны дублироваться с точки зрения атрибутов, ограничиваемых решающим индексом или ограничением.
Заметьте, что в настоящий момент не поддерживается ситуация, когда конструкция ON CONFLICT DO UPDATE
команды INSERT
, применяемой к секционированной таблице, изменяет ключ секционирования в конфликтующей строке так, что эта строка должна быть перенесена в новую секцию.
Подсказка
Часто предпочтительнее использовать неявный выбор уникального индекса вместо непосредственного указания ограничения в виде ON CONFLICT ON CONSTRAINT
имя_ограничения
. Выбор продолжит корректно работать, когда нижележащий индекс будет заменён другим более или менее равнозначным индексом методом наложения, например, с использованием CREATE UNIQUE INDEX ... CONCURRENTLY
и последующим удалением заменяемого индекса.
Выводимая информация
В случае успешного завершения INSERT
возвращает метку команды в виде
INSERToid
число
Здесь число
представляет количество добавленных или изменённых строк. Поле oid
всегда содержит 0 (раньше в нём выводился OID, присвоенный добавленной строке, когда число
равнялось 1 и целевая таблица была создана с указанием WITH OIDS
, а в противном случае — 0; теперь же создание таблицы с характеристикой WITH OIDS
не поддерживается).
Если команда INSERT
содержит предложение RETURNING
, её результат будет похож на результат оператора SELECT
(с теми же столбцами и значениями, что содержатся в списке RETURNING
), полученный для строк, добавленных или изменённых этой командой.
Примечания
Если целевая таблица является секционированной, каждая строка перенаправляется в соответствующую секцию и вставляется в неё. Если целевая таблица является секцией и какая-либо из входных строк нарушает ограничение этой секции, происходит ошибка.
Примеры
Добавление одной строки в таблицу films
:
INSERT INTO films VALUES ('UA502', 'Bananas', 105, '1971-07-13', 'Comedy', '82 minutes');
В этом примере столбец len
опускается и, таким образом, получает значение по умолчанию:
INSERT INTO films (code, title, did, date_prod, kind) VALUES ('T_601', 'Yojimbo', 106, '1961-06-16', 'Drama');
В этом примере для столбца с датой задаётся указание DEFAULT
, а не явное значение:
INSERT INTO films VALUES ('UA502', 'Bananas', 105, DEFAULT, 'Comedy', '82 minutes'); INSERT INTO films (code, title, did, date_prod, kind) VALUES ('T_601', 'Yojimbo', 106, DEFAULT, 'Drama');
Добавление строки, полностью состоящей из значений по умолчанию:
INSERT INTO films DEFAULT VALUES;
Добавление нескольких строк с использованием многострочного синтаксиса VALUES
:
INSERT INTO films (code, title, did, date_prod, kind) VALUES ('B6717', 'Tampopo', 110, '1985-02-10', 'Comedy'), ('HG120', 'The Dinner Game', 140, DEFAULT, 'Comedy');
В этом примере в таблицу films
вставляются некоторые строки из таблицы tmp_films
, имеющей ту же структуру столбцов, что и films
:
INSERT INTO films SELECT * FROM tmp_films WHERE date_prod < '2004-05-07';
Этот пример демонстрирует добавление данных в столбцы с типом массива:
-- Создание пустого поля 3x3 для игры в крестики-нолики INSERT INTO tictactoe (game, board[1:3][1:3]) VALUES (1, '{{" "," "," "},{" "," "," "},{" "," "," "}}'); -- Указания индексов в предыдущей команда могут быть опущены INSERT INTO tictactoe (game, board) VALUES (2, '{{X," "," "},{" ",O," "},{" ",X," "}}');
Добавление одной строки в таблицу distributors
и получение последовательного номера, сгенерированного благодаря указанию DEFAULT
:
INSERT INTO distributors (did, dname) VALUES (DEFAULT, 'XYZ Widgets') RETURNING did;
Увеличение счётчика продаж для продавца, занимающегося компанией Acme Corporation, и сохранение всей изменённой строки вместе с текущим временем в таблице журнала:
WITH upd AS ( UPDATE employees SET sales_count = sales_count + 1 WHERE id = (SELECT sales_person FROM accounts WHERE name = 'Acme Corporation') RETURNING * ) INSERT INTO employees_log SELECT *, current_timestamp FROM upd;
Добавить дистрибьюторов или изменить существующие данные должным образом. Предполагается, что в таблице определён уникальный индекс, ограничивающий значения в столбце did
. Заметьте, что для обращения к значениям, изначально предлагаемым для добавления, используется специальная таблица excluded
:
INSERT INTO distributors (did, dname) VALUES (5, 'Gizmo Transglobal'), (6, 'Associated Computing, Inc') ON CONFLICT (did) DO UPDATE SET dname = EXCLUDED.dname;
Добавить дистрибьютора или не делать ничего для строк, предложенных для добавления, если уже есть существующая исключающая строка (строка, содержащая конфликтующие значения в столбце или столбцах после срабатывания триггеров перед добавлением строки). В данном примере предполагается, что определён уникальный индекс, ограничивающий значения в столбце did
:
INSERT INTO distributors (did, dname) VALUES (7, 'Redline GmbH') ON CONFLICT (did) DO NOTHING;
Добавить дистрибьюторов или изменить существующие данные должным образом. В данном примере предполагается, что в таблице определён уникальный индекс, ограничивающий значения в столбце did
. Предложение WHERE
позволяет ограничить набор фактически изменяемых строк (однако любая существующая строка, не подлежащая изменению, всё же будет заблокирована):
-- Не менять данные существующих дистрибьюторов в зависимости от почтового индекса INSERT INTO distributors AS d (did, dname) VALUES (8, 'Anvil Distribution') ON CONFLICT (did) DO UPDATE SET dname = EXCLUDED.dname || ' (formerly ' || d.dname || ')' WHERE d.zipcode <> '21201'; -- Указать имя ограничения непосредственно в операторе (связанный индекс -- применяется для принятия решения о выполнении действия DO NOTHING) INSERT INTO distributors (did, dname) VALUES (9, 'Antwerp Design') ON CONFLICT ON CONSTRAINT distributors_pkey DO NOTHING;
Добавить дистрибьютора, если возможно; в противном случае не делать ничего (DO NOTHING
). В данном примере предполагается, что в таблице определён уникальный индекс, ограничивающий значения в столбце did
по подмножеству строк, в котором логический столбец is_active
содержит true
:
-- Этот оператор может выбрать частичный уникальный индекс по "did" -- с предикатом "WHERE is_active", а может и просто использовать -- обычное ограничение уникальности по столбцу "did" INSERT INTO distributors (did, dname) VALUES (10, 'Conrad International') ON CONFLICT (did) WHERE is_active DO NOTHING;
Совместимость
INSERT
соответствует стандарту SQL, но предложение RETURNING
относится к расширениям Postgres Pro, как и возможность применять WITH
с INSERT
и возможность задавать альтернативное действие с ON CONFLICT
. Кроме того, ситуация, когда список столбцов опущен, но не все столбцы получают значения из предложения VALUES
или запроса
, стандартом не допускается.
В стандарте SQL говорится, что предложение OVERRIDING SYSTEM VALUE
может присутствовать, только если существует столбец идентификации, для которого всегда генерируется значение. Postgres Pro допускает это предложение в любом случае и игнорирует его в случае неприменимости.
Возможные ограничения предложения запрос
описаны в справке SELECT.
28.4. Progress Reporting #
PostgreSQL has the ability to report the progress of certain commands during command execution. Currently, the only commands which support progress reporting are ANALYZE
, CLUSTER
, CREATE INDEX
, VACUUM
, COPY
, and BASE_BACKUP (i.e., replication command that pg_basebackup issues to take a base backup). This may be expanded in the future.
28.4.1. ANALYZE Progress Reporting #
Whenever ANALYZE
is running, the pg_stat_progress_analyze
view will contain a row for each backend that is currently running that command. The tables below describe the information that will be reported and provide information about how to interpret it.
Table 28.37. pg_stat_progress_analyze
View
Column Type Description |
---|
Process ID of backend. |
OID of the database to which this backend is connected. |
Name of the database to which this backend is connected. |
OID of the table being analyzed. |
Current processing phase. See Table 28.38. |
Total number of heap blocks that will be sampled. |
Number of heap blocks scanned. |
Number of extended statistics. |
Number of extended statistics computed. This counter only advances when the phase is |
Number of child tables. |
Number of child tables scanned. This counter only advances when the phase is |
OID of the child table currently being scanned. This field is only valid when the phase is |
Table 28.38. ANALYZE Phases
Phase | Description |
---|---|
initializing | The command is preparing to begin scanning the heap. This phase is expected to be very brief. |
acquiring sample rows | The command is currently scanning the table given by relid to obtain sample rows. |
acquiring inherited sample rows | The command is currently scanning child tables to obtain sample rows. Columns child_tables_total , child_tables_done , and current_child_table_relid contain the progress information for this phase. |
computing statistics | The command is computing statistics from the sample rows obtained during the table scan. |
computing extended statistics | The command is computing extended statistics from the sample rows obtained during the table scan. |
finalizing analyze | The command is updating pg_class . When this phase is completed, ANALYZE will end. |
Note
Note that when ANALYZE
is run on a partitioned table, all of its partitions are also recursively analyzed. In that case, ANALYZE
progress is reported first for the parent table, whereby its inheritance statistics are collected, followed by that for each partition.
28.4.2. CLUSTER Progress Reporting #
Whenever CLUSTER
or VACUUM FULL
is running, the pg_stat_progress_cluster
view will contain a row for each backend that is currently running either command. The tables below describe the information that will be reported and provide information about how to interpret it.
Table 28.39. pg_stat_progress_cluster
View
Column Type Description |
---|
Process ID of backend. |
OID of the database to which this backend is connected. |
Name of the database to which this backend is connected. |
OID of the table being clustered. |
The command that is running. Either |
Current processing phase. See Table 28.40. |
If the table is being scanned using an index, this is the OID of the index being used; otherwise, it is zero. |
Number of heap tuples scanned. This counter only advances when the phase is |
Number of heap tuples written. This counter only advances when the phase is |
Total number of heap blocks in the table. This number is reported as of the beginning of |
Number of heap blocks scanned. This counter only advances when the phase is |
Number of indexes rebuilt. This counter only advances when the phase is |
Table 28.40. CLUSTER and VACUUM FULL Phases
Phase | Description |
---|---|
initializing | The command is preparing to begin scanning the heap. This phase is expected to be very brief. |
seq scanning heap | The command is currently scanning the table using a sequential scan. |
index scanning heap | CLUSTER is currently scanning the table using an index scan. |
sorting tuples | CLUSTER is currently sorting tuples. |
writing new heap | CLUSTER is currently writing the new heap. |
swapping relation files | The command is currently swapping newly-built files into place. |
rebuilding index | The command is currently rebuilding an index. |
performing final cleanup | The command is performing final cleanup. When this phase is completed, CLUSTER or VACUUM FULL will end. |
28.4.3. COPY Progress Reporting #
Whenever COPY
is running, the pg_stat_progress_copy
view will contain one row for each backend that is currently running a COPY
command. The table below describes the information that will be reported and provides information about how to interpret it.
Table 28.41. pg_stat_progress_copy
View
Column Type Description |
---|
Process ID of backend. |
OID of the database to which this backend is connected. |
Name of the database to which this backend is connected. |
OID of the table on which the |
The command that is running: |
The io type that the data is read from or written to: |
Number of bytes already processed by |
Size of source file for |
Number of tuples already processed by |
Number of tuples not processed because they were excluded by the |
28.4.4. CREATE INDEX Progress Reporting #
Whenever CREATE INDEX
or REINDEX
is running, the pg_stat_progress_create_index
view will contain one row for each backend that is currently creating indexes. The tables below describe the information that will be reported and provide information about how to interpret it.
Table 28.42. pg_stat_progress_create_index
View
Column Type Description |
---|
Process ID of the backend creating indexes. |
OID of the database to which this backend is connected. |
Name of the database to which this backend is connected. |
OID of the table on which the index is being created. |
OID of the index being created or reindexed. During a non-concurrent |
Specific command type: |
Current processing phase of index creation. See Table 28.43. |
Total number of lockers to wait for, when applicable. |
Number of lockers already waited for. |
Process ID of the locker currently being waited for. |
Total number of blocks to be processed in the current phase. |
Number of blocks already processed in the current phase. |
Total number of tuples to be processed in the current phase. |
Number of tuples already processed in the current phase. |
Total number of partitions on which the index is to be created or attached, including both direct and indirect partitions. |
Number of partitions on which the index has already been created or attached, including both direct and indirect partitions. |
Table 28.43. CREATE INDEX Phases
Phase | Description |
---|---|
initializing | CREATE INDEX or REINDEX is preparing to create the index. This phase is expected to be very brief. |
waiting for writers before build | CREATE INDEX CONCURRENTLY or REINDEX CONCURRENTLY is waiting for transactions with write locks that can potentially see the table to finish. This phase is skipped when not in concurrent mode. Columns lockers_total , lockers_done and current_locker_pid contain the progress information for this phase. |
building index | The index is being built by the access method-specific code. In this phase, access methods that support progress reporting fill in their own progress data, and the subphase is indicated in this column. Typically, blocks_total and blocks_done will contain progress data, as well as potentially tuples_total and tuples_done . |
waiting for writers before validation | CREATE INDEX CONCURRENTLY or REINDEX CONCURRENTLY is waiting for transactions with write locks that can potentially write into the table to finish. This phase is skipped when not in concurrent mode. Columns lockers_total , lockers_done and current_locker_pid contain the progress information for this phase. |
index validation: scanning index | CREATE INDEX CONCURRENTLY is scanning the index searching for tuples that need to be validated. This phase is skipped when not in concurrent mode. Columns blocks_total (set to the total size of the index) and blocks_done contain the progress information for this phase. |
index validation: sorting tuples | CREATE INDEX CONCURRENTLY is sorting the output of the index scanning phase. |
index validation: scanning table | CREATE INDEX CONCURRENTLY is scanning the table to validate the index tuples collected in the previous two phases. This phase is skipped when not in concurrent mode. Columns blocks_total (set to the total size of the table) and blocks_done contain the progress information for this phase. |
waiting for old snapshots | CREATE INDEX CONCURRENTLY or REINDEX CONCURRENTLY is waiting for transactions that can potentially see the table to release their snapshots. This phase is skipped when not in concurrent mode. Columns lockers_total , lockers_done and current_locker_pid contain the progress information for this phase. |
waiting for readers before marking dead | REINDEX CONCURRENTLY is waiting for transactions with read locks on the table to finish, before marking the old index dead. This phase is skipped when not in concurrent mode. Columns lockers_total , lockers_done and current_locker_pid contain the progress information for this phase. |
waiting for readers before dropping | REINDEX CONCURRENTLY is waiting for transactions with read locks on the table to finish, before dropping the old index. This phase is skipped when not in concurrent mode. Columns lockers_total , lockers_done and current_locker_pid contain the progress information for this phase. |
28.4.5. VACUUM Progress Reporting #
Whenever VACUUM
is running, the pg_stat_progress_vacuum
view will contain one row for each backend (including autovacuum worker processes) that is currently vacuuming. The tables below describe the information that will be reported and provide information about how to interpret it. Progress for VACUUM FULL
commands is reported via pg_stat_progress_cluster
because both VACUUM FULL
and CLUSTER
rewrite the table, while regular VACUUM
only modifies it in place. See Section 28.4.2.
Table 28.44. pg_stat_progress_vacuum
View
Column Type Description |
---|
Process ID of backend. |
OID of the database to which this backend is connected. |
Name of the database to which this backend is connected. |
OID of the table being vacuumed. |
Current processing phase of vacuum. See Table 28.45. |
Total number of heap blocks in the table. This number is reported as of the beginning of the scan; blocks added later will not be (and need not be) visited by this |
Number of heap blocks scanned. Because the visibility map is used to optimize scans, some blocks will be skipped without inspection; skipped blocks are included in this total, so that this number will eventually become equal to |
Number of heap blocks vacuumed. Unless the table has no indexes, this counter only advances when the phase is |
Number of completed index vacuum cycles. |
Number of dead tuples that we can store before needing to perform an index vacuum cycle, based on maintenance_work_mem. |
Number of dead tuples collected since the last index vacuum cycle. |
Table 28.45. VACUUM Phases
Phase | Description |
---|---|
initializing | VACUUM is preparing to begin scanning the heap. This phase is expected to be very brief. |
scanning heap | VACUUM is currently scanning the heap. It will prune and defragment each page if required, and possibly perform freezing activity. The heap_blks_scanned column can be used to monitor the progress of the scan. |
vacuuming indexes | VACUUM is currently vacuuming the indexes. If a table has any indexes, this will happen at least once per vacuum, after the heap has been completely scanned. It may happen multiple times per vacuum if maintenance_work_mem (or, in the case of autovacuum, autovacuum_work_mem if set) is insufficient to store the number of dead tuples found. |
vacuuming heap | VACUUM is currently vacuuming the heap. Vacuuming the heap is distinct from scanning the heap, and occurs after each instance of vacuuming indexes. If heap_blks_scanned is less than heap_blks_total , the system will return to scanning the heap after this phase is completed; otherwise, it will begin cleaning up indexes after this phase is completed. |
cleaning up indexes | VACUUM is currently cleaning up indexes. This occurs after the heap has been completely scanned and all vacuuming of the indexes and the heap has been completed. |
truncating heap | VACUUM is currently truncating the heap so as to return empty pages at the end of the relation to the operating system. This occurs after cleaning up indexes. |
performing final cleanup | VACUUM is performing final cleanup. During this phase, VACUUM will vacuum the free space map, update statistics in pg_class , and report statistics to the cumulative statistics system. When this phase is completed, VACUUM will end. |
28.4.6. Base Backup Progress Reporting #
Whenever an application like pg_basebackup is taking a base backup, the pg_stat_progress_basebackup
view will contain a row for each WAL sender process that is currently running the BASE_BACKUP
replication command and streaming the backup. The tables below describe the information that will be reported and provide information about how to interpret it.
Table 28.46. pg_stat_progress_basebackup
View
Column Type Description |
---|
Process ID of a WAL sender process. |
Current processing phase. See Table 28.47. |
Total amount of data that will be streamed. This is estimated and reported as of the beginning of |
Amount of data streamed. This counter only advances when the phase is |
Total number of tablespaces that will be streamed. |
Number of tablespaces streamed. This counter only advances when the phase is |
Table 28.47. Base Backup Phases
Phase | Description |
---|---|
initializing | The WAL sender process is preparing to begin the backup. This phase is expected to be very brief. |
waiting for checkpoint to finish | The WAL sender process is currently performing pg_backup_start to prepare to take a base backup, and waiting for the start-of-backup checkpoint to finish. |
estimating backup size | The WAL sender process is currently estimating the total amount of database files that will be streamed as a base backup. |
streaming database files | The WAL sender process is currently streaming database files as a base backup. |
waiting for wal archiving to finish | The WAL sender process is currently performing pg_backup_stop to finish the backup, and waiting for all the WAL files required for the base backup to be successfully archived. If either --wal-method=none or --wal-method=stream is specified in pg_basebackup, the backup will end when this phase is completed. |
transferring wal files | The WAL sender process is currently transferring all WAL logs generated during the backup. This phase occurs after waiting for wal archiving to finish phase if --wal-method=fetch is specified in pg_basebackup. The backup will end when this phase is completed. |