11.1. Введение
Предположим, что у нас есть такая таблица:
CREATE TABLE test1 ( id integer, content varchar );
и приложение выполняет много подобных запросов:
SELECT content FROM test1 WHERE id = константа
;
Если система не будет заранее подготовлена, ей придётся сканировать всю таблицу test1
, строку за строкой, чтобы найти все подходящие записи. Когда таблица test1
содержит большое количество записей, а этот запрос должен вернуть всего несколько (возможно, одну или ноль), такое сканирование, очевидно, неэффективно. Но если создать в системе индекс по полю id
, она сможет находить строки гораздо быстрее. Возможно, для этого ей понадобится опуститься всего на несколько уровней в дереве поиска.
Подобный подход часто используется в технической литературе: термины и понятия, которые могут представлять интерес, собираются в алфавитном указателе в конце книги. Читатель может просмотреть этот указатель довольно быстро и затем перейти сразу к соответствующей странице, вместо того, чтобы пролистывать всю книгу в поисках нужного материала. Так же, как задача автора предугадать, что именно будут искать в книге читатели, задача программиста баз данных — заранее определить, какие индексы будут полезны.
Создать индекс для столбца id
рассмотренной ранее таблицы можно с помощью следующей команды:
CREATE INDEX test1_id_index ON test1 (id);
Имя индекса test1_id_index
может быть произвольным, главное, чтобы оно позволяло понять, для чего этот индекс.
Для удаления индекса используется команда DROP INDEX
. Добавлять и удалять индексы можно в любое время.
Когда индекс создан, никакие дополнительные действия не требуются: система сама будет обновлять его при изменении данных в таблице и сама будет использовать его в запросах, где, по её мнению, это будет эффективнее, чем сканирование всей таблицы. Вам, возможно, придётся только периодически запускать команду ANALYZE
для обновления статистических данных, на основе которых планировщик запросов принимает решения. В Главе 14 вы можете узнать, как определить, используется ли определённый индекс и при каких условиях планировщик может решить не использовать его.
Индексы могут быть полезны также при выполнении команд UPDATE
и DELETE
с условиями поиска. Кроме того, они могут применяться в поиске с соединением. То есть, индекс, определённый для столбца, участвующего в условии соединения, может значительно ускорить запросы с JOIN.
Создание индекса для большой таблицы может занимать много времени. По умолчанию Postgres Pro позволяет параллельно с созданием индекса выполнять чтение (операторы SELECT
) таблицы, но операции записи (INSERT
, UPDATE
и DELETE
) блокируются до окончания построения индекса. Для производственной среды это ограничение часто бывает неприемлемым. Хотя есть возможность разрешить запись параллельно с созданием индексов, при этом нужно учитывать ряд оговорок — они описаны в подразделе Неблокирующее построение индексов.
После создания индекса система должна поддерживать его в состоянии, соответствующем данным таблицы. С этим связаны неизбежные накладные расходы при изменении данных. Таким образом, индексы, которые используются в запросах редко или вообще никогда, должны быть удалены.
pg_xlogdump
pg_xlogdump — display a human-readable rendering of the write-ahead log of a Postgres Pro database cluster
Synopsis
pg_xlogdump
[option
...] [startseg
[endseg
] ]
Description
pg_xlogdump
displays the write-ahead log (WAL) and is mainly useful for debugging or educational purposes.
This utility can only be run by the user who installed the server, because it requires read-only access to the data directory.
Options
The following command-line options control the location and format of the output:
startseg
Start reading at the specified log segment file. This implicitly determines the path in which files will be searched for, and the timeline to use.
endseg
Stop after reading the specified log segment file.
-b
--bkp-details
Output detailed information about backup blocks.
-e
end
--end=
end
Stop reading at the specified log position, instead of reading to the end of the log stream.
-f
--follow
After reaching the end of valid WAL, keep polling once per second for new WAL to appear.
-n
limit
--limit=
limit
Display the specified number of records, then stop.
-p
path
--path=
path
Specifies a directory to search for log segment files or a directory with a
pg_xlog
subdirectory that contains such files. The default is to search in the current directory, thepg_xlog
subdirectory of the current directory, and thepg_xlog
subdirectory ofPGDATA
.-r
rmgr
--rmgr=
rmgr
Only display records generated by the specified resource manager. If
list
is passed as name, print a list of valid resource manager names, and exit.-s
start
--start=
start
Log position at which to start reading. The default is to start reading the first valid log record found in the earliest file found.
-t
timeline
--timeline=
timeline
Timeline from which to read log records. The default is to use the value in
startseg
, if that is specified; otherwise, the default is 1.-V
--version
Print the pg_xlogdump version and exit.
-x
xid
--xid=
xid
Only display records marked with the given transaction ID.
-z
--stats[=record]
Display summary statistics (number and size of records and full-page images) instead of individual records. Optionally generate statistics per-record instead of per-rmgr.
-?
--help
Show help about pg_xlogdump command line arguments, and exit.
Notes
Can give wrong results when the server is running.
Only the specified timeline is displayed (or the default, if none is specified). Records in other timelines are ignored.
pg_xlogdump cannot read WAL files with suffix .partial
. If those files need to be read, .partial
suffix needs to be removed from the file name.