postgresql/src/backend/utils
Andres Freund 31966b151e 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
2023-04-05 16:21:09 -07:00
..
activity bufmgr: Introduce infrastructure for faster relation extension 2023-04-05 16:21:09 -07:00
adt Fix MSVC warning introduced in ea1db8ae70. 2023-04-04 15:43:18 -07:00
cache Acquire locks on views in AcquirePlannerLocks, too. 2023-04-05 15:56:35 -04:00
error Update copyright for 2023 2023-01-02 15:00:37 -05:00
fmgr Add SysCacheGetAttrNotNull for guaranteed not-null attrs 2023-03-25 22:49:33 +01:00
hash Update copyright for 2023 2023-01-02 15:00:37 -05:00
init Fix wrong word in comment. 2023-04-05 09:50:08 -04:00
mb New header varatt.h split off from postgres.h 2023-01-10 05:54:36 +01:00
misc Validate ICU locales. 2023-03-28 16:34:29 -07:00
mmgr Fix minor signed/unsigned mixup 2023-04-05 07:34:52 +02:00
resowner bufmgr: Support multiple in-progress IOs by using resowner 2023-04-05 14:17:55 -07:00
sort Pass down table relation into more index relation functions 2023-04-01 20:18:29 -07:00
time Remove useless casts to (void *) in hash_search() calls 2023-02-06 09:41:01 +01:00
.gitignore Rearrange makefile rules for running Gen_fmgrtab.pl. 2018-05-03 17:54:18 -04:00
errcodes.txt Update copyright for 2023 2023-01-02 15:00:37 -05:00
Gen_dummy_probes.pl Update copyright for 2023 2023-01-02 15:00:37 -05:00
Gen_dummy_probes.pl.prolog Update copyright for 2023 2023-01-02 15:00:37 -05:00
Gen_dummy_probes.sed Update copyright for 2023 2023-01-02 15:00:37 -05:00
Gen_fmgrtab.pl Update copyright for 2023 2023-01-02 15:00:37 -05:00
generate-errcodes.pl Update copyright for 2023 2023-01-02 15:00:37 -05:00
Makefile Update copyright for 2023 2023-01-02 15:00:37 -05:00
meson.build Update copyright for 2023 2023-01-02 15:00:37 -05:00
postprocess_dtrace.sed Update copyright for 2023 2023-01-02 15:00:37 -05:00
probes.d bufmgr: Introduce infrastructure for faster relation extension 2023-04-05 16:21:09 -07:00
README.Gen_dummy_probes Tweak generation of Gen_dummy_probes.pl 2021-05-11 20:02:02 -04:00

# Generating dummy probes

If Postgres isn't configured with dtrace enabled, we need to generate
dummy probes for the entries in probes.d, that do nothing.

This is accomplished in Unix via the sed script `Gen_dummy_probes.sed`. We
used to use this in MSVC builds using the perl utility `psed`, which mimicked
sed. However, that utility disappeared from Windows perl distributions and so
we converted the sed script to a perl script to be used in MSVC builds.

We still keep the sed script as the authoritative source for generating
these dummy probes because except on Windows perl is not a hard requirement
when building from a tarball.

So, if you need to change the way dummy probes are generated, first change
the sed script, and when it's working generate the perl script. This can
be accomplished by using the perl utility s2p.

s2p is no longer part of the perl core, so it might not be on your system,
but it is available on CPAN and also in many package systems. e.g.
on Fedora it can be installed using `cpan App::s2p` or
`dnf install perl-App-s2p`.

The Makefile contains a recipe for regenerating Gen_dummy_probes.pl, so all
you need to do is once you have s2p installed is `make Gen_dummy_probes.pl`
Note that in a VPATH build this will generate the file in the vpath tree,
not the source tree.