Skip to content
Snippets Groups Projects
Commit 28f57fdc authored by Radko Krkoš's avatar Radko Krkoš
Browse files

Update Database documentation for PostgreSQL v13.x

(Redmine issue: #6610)
parent 6b7cf698
No related branches found
No related tags found
No related merge requests found
......@@ -54,7 +54,7 @@ database on following hardware:
General settings and performance optimizations
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Following options were changed in the main configuration file ``/etc/postgresql/12/main/postgresql.conf``:
Following options were changed in the main configuration file ``/etc/postgresql/13/main/postgresql.conf``:
.. code-block:: shell
......@@ -104,7 +104,7 @@ information according to PostgreSQL best practices.
Import tuning
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Following options were changed in the main configuration file ``/etc/postgresql/12/main/postgresql.conf``:
Following options were changed in the main configuration file ``/etc/postgresql/13/main/postgresql.conf``:
.. code-block:: shell
......@@ -123,7 +123,7 @@ Following options were changed in the main configuration file ``/etc/postgresql/
Enabling query parallelism
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Following options were changed in the main configuration file ``/etc/postgresql/12/main/postgresql.conf``:
Following options were changed in the main configuration file ``/etc/postgresql/13/main/postgresql.conf``:
As of PostgreSQL 9.6, with significant further improvements in 10.0 and gradual in 11.0 and 12.0, individual queries can be performed by parallel subworkers. Default settings are very conservative and allow this type of parallelism only in extreme cases and with very few workers. For any system, configuration has to be tuned individually. List of changes to improve parallelism follows:
......@@ -202,6 +202,12 @@ Regular VACUUM and ANALYZE
* A multiplicative parameter for depth of analysis for ``ANALYZE``, it allows for a trade-off between ``ANALYZE`` speed and relative frequency data precision by defining statistic subset size. Default value of 100 is reasonable for smaller tables or tables with roughly uniform distribution of individual values in columns. As ``AUTOANALYZE`` is performed in the background and requires no lock, we can allow for a higher value allowing for better query plans. If the number of rows grows in the future, it might be a good idea to scale this value accordingly to allow for good estimations for the more rare of values.
.. code-block:: shell
autovacuum_vacuum_insert_threshold = -1
* In PostgreSQL v13.x, the default ``AUTOVACUUM`` behaviour was changed for the mechanism also to be triggered by ``INSERTs`` in addition to ``DELETEs`` and ``UPDATEs`` as before. While this is generally useful for multi-version heavy workloads with ``ROLLBACKs`` where bloat can also occur in ``INSERT`` only load, in the Mentat import pipeline this happens extremely rarely (there ``SHOULD NOT`` be conflicting events coming in). The Mentat database management does not depend much on ``AUTOVACUUM`` for bloat management (as opposed on ``AUTOANALYZE``, which is used heavily), and triggers manual ``VACUUMs`` after ``DELETEs`` in the cleaner. Changing ``autovacuum_vacuum_insert_threshold`` to -1 restores the previous behaviour (default until v12.x), where ``INSERTs`` alone never trigger the ``AUTOVACUUM``. This prevents congestion and high disk-load situations which would otherwise affect the performance of the system as a whole.
.. code-block:: sql
psql mentat_events
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment