Since the early version 7.4, when the only process running the cluster were the
old loved postmaster, PostgreSQL has enriched with new dedicated processes,
becoming more complex but even more efficient.
With a running cluster there are at least six postgres processes, the one
without colon in the process name is is the main database's process, started
as seen in the section 4.2.
postgres: checkpointer process
As the name suggest this process take care of the cluster's
checkpoint. The checkpoint is an important event in the
database activity. When a checkpoint starts all the dirty
pages in memory are written to the data files.
The checkpoint by the time and the number of cluster's WAL switches.
To adjust the checkpoin's frequency the GUC parameters checkpoint_timeout and
checkpoint_segments are used. A third parameter,
checkpoint_completion_target is used to spread the checkpoint over a
percentage of the checkpoint_timeout, in order to avoid a massive disk IO
postgres: writer process
To ease down the checkpoint activity the background writer scans the shared
buffer for dirty pages to write down to the disk. The process is designed to
have a minimal impact on the database activity. It's possible to tune the rounds
length and delay using the GUC parameters bgwriter_delay, time between two
rounds, and bgwriter_lru_maxpages, the number of buffers after the writer's
postgres: wal writer process
This background process has been introduced recently to have a more efficient
wal writing. The process works in rounds were write down the wal buffers to the
wal files. The GUC parameter wal_writer_delay sets
the milliseconds to sleep between the rounds.
postgres: autovacuum launcher process
This process is present if the GUC parameter autovacuum is set to on.
It's scope is to launch the autovacuum backends at need.
Anyway autovacuum can run even if autovacuum is turned of, when there's risk
of the XID wraparound failure.
postgres: stats collector process
The process gathers the database's usage statistics for human usage and stores
the informations into the location indicated by the GUC stats_temp_directory,
by default pg_stat_temp. Those statistics are useful to understand
how the database is performing, from pyshical and logical point of view.
postgres: postgres postgres [local] idle
This kind of process is the database backend, one for each established
connection. The values after the colon square brackets show useful
informations like the connected database, the username, the host and the
executing query. The same informations are stored into the pg_stat_activity