pgsql: bufmgr: Introduce infrastructure for faster relation extension

Поиск
Список
Период
Сортировка
От Andres Freund
Тема pgsql: bufmgr: Introduce infrastructure for faster relation extension
Дата
Msg-id E1pkDKV-001ZVp-Tk@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
bufmgr: Introduce infrastructure for faster relation extension

The primary bottlenecks for relation extension are:

1) The extension lock is held while acquiring a victim buffer for the new
   page. Acquiring a victim buffer can require writing out the old page
   contents including possibly needing to flush WAL.

2) When extending via ReadBuffer() et al, we write a zero page during the
   extension, and then later write out the actual page contents. This can
   nearly double the write rate.

3) The existing bulk relation extension infrastructure in hio.c just amortized
   the cost of acquiring the relation extension lock, but none of the other
   costs.

Unfortunately 1) cannot currently be addressed in a central manner as the
callers to ReadBuffer() need to acquire the extension lock. To address that,
this this commit moves the responsibility for acquiring the extension lock
into bufmgr.c functions. That allows to acquire the relation extension lock
for just the required time. This will also allow us to improve relation
extension further, without changing callers.

The reason we write all-zeroes pages during relation extension is that we hope
to get ENOSPC errors earlier that way (largely works, except for CoW
filesystems). It is easier to handle out-of-space errors gracefully if the
page doesn't yet contain actual tuples. This commit addresses 2), by using the
recently introduced smgrzeroextend(), which extends the relation, without
dirtying the kernel page cache for all the extended pages.

To address 3), this commit introduces a function to extend a relation by
multiple blocks at a time.

There are three new exposed functions: ExtendBufferedRel() for extending the
relation by a single block, ExtendBufferedRelBy() to extend a relation by
multiple blocks at once, and ExtendBufferedRelTo() for extending a relation up
to a certain size.

To avoid duplicating code between ReadBuffer(P_NEW) and the new functions,
ReadBuffer(P_NEW) now implements relation extension with
ExtendBufferedRel(), using a flag to tell ExtendBufferedRel() that the
relation lock is already held.

Note that this commit does not yet lead to a meaningful performance or
scalability improvement - for that uses of ReadBuffer(P_NEW) will need to be
converted to ExtendBuffered*(), which will be done in subsequent commits.

Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi>
Reviewed-by: Melanie Plageman <melanieplageman@gmail.com>
Discussion: https://postgr.es/m/20221029025420.eplyow6k7tgu6he3@awork3.anarazel.de

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/31966b151e6ab7a6284deab6e8fe5faddaf2ae4c

Modified Files
--------------
doc/src/sgml/monitoring.sgml           |  43 +-
src/backend/storage/buffer/bufmgr.c    | 794 ++++++++++++++++++++++++++-------
src/backend/storage/buffer/localbuf.c  | 156 ++++++-
src/backend/utils/activity/pgstat_io.c |   8 +-
src/backend/utils/probes.d             |   6 +-
src/include/pgstat.h                   |   1 +
src/include/storage/buf_internals.h    |   7 +
src/include/storage/bufmgr.h           |  65 +++
src/tools/pgindent/typedefs.list       |   2 +
9 files changed, 901 insertions(+), 181 deletions(-)


В списке pgsql-committers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pgsql: Don't initialize page in {vm,fsm}_extend(), not needed
Следующее
От: Michael Paquier
Дата:
Сообщение: pgsql: Fix row tracking in pg_stat_statements with extended query proto