Serverparameter der Azure Cosmos DB for PostgreSQL
GILT FÜR: Azure Cosmos DB for PostgreSQL (unterstützt von der Citus-Datenbankerweiterung auf PostgreSQL)
Es gibt verschiedene Serverparameter, die sich auf das Verhalten von Azure Cosmos DB for PostgreSQL auswirken, sowohl aus Standard-PostgreSQL als auch speziell für Azure Cosmos DB for PostgreSQL. Diese Parameter können im Azure-Portal für einen Cluster festgelegt werden. Wählen Sie hierzu unter der Kategorie Einstellungen die Parameter Workerknoten oder Option Koordinatorknoten aus. Auf diesen Seiten können Sie Parameter für alle Workerknoten oder nur für den Koordinatorknoten festlegen.
Azure Cosmos DB for PostgreSQL-Parameter
Hinweis
Cluster, auf denen ältere Versionen der Citus-Erweiterung ausgeführt werden, bieten möglicherweise nicht alle unten aufgeführten Parameter.
Allgemeine Konfiguration
citus.use_secondary_nodes (Enumeration)
Legt die Richtlinie fest, die beim Auswählen von Knoten für SELECT-Abfragen verwendet werden soll. Wenn dies auf „immer“ festgelegt ist, fragt der Planer nur Knoten ab, die in pg_dist_node als „sekundäre“ Knotenrolle gekennzeichnet sind.
Die unterstützten Werte für diese Enumeration lauten:
- never: (Standardwert) Alle Lesevorgänge erfolgen auf primären Knoten.
- always: Lesevorgänge werden stattdessen für sekundäre Knoten ausgeführt, und insert-/update-Anweisungen sind deaktiviert.
citus.cluster_name (Text)
Informiert den Koordinatorknotenplaner, welchen Cluster er koordiniert. Nachdem cluster_name festgelegt wurde, fragt der Planer die Workerknoten nur in diesem Cluster ab.
citus.enable_version_checks (boolescher Wert)
Für ein Versionsupgrade von Azure Cosmos DB for PostgreSQL ist ein Neustart des Servers erforderlich (um die neue freigegebene Bibliothek einzubinden), gefolgt vom Befehl ALTER EXTENSION UPDATE. Wenn nicht beide Schritte ausgeführt werden, kann dies potenziell zu Fehlern oder Abstürzen führen. Azure Cosmos DB for PostgreSQL überprüft daher die Version des Codes und die Übereinstimmung mit der Erweiterung und gibt Fehler aus, wenn dies nicht der Fall ist.
Dieser Wert ist standardmäßig TRUE und für den Koordinator gültig. In seltenen Fällen ist es für komplexe Upgradeprozesse möglicherweise erforderlich, diesen Parameter auf FALSE festzulegen und so die Überprüfung zu deaktivieren.
citus.log_distributed_deadlock_detection (boolescher Wert)
Gibt an, ob die Verarbeitung verteilter Deadlockerkennungen im Serverprotokoll protokolliert werden soll. Der Standardwert ist FALSE.
citus.distributed_deadlock_detection_factor (Gleitkommawert)
Legt die Wartezeit bis zur Suche nach verteilten Deadlocks fest. Insbesondere ist die Wartezeit dieser Wert multipliziert mit der deadlock_timeout-Einstellung von PostgreSQL. Der Standardwert ist 2
. Der Wert -1
deaktiviert die Erkennung verteilter Deadlocks.
citus.node_connection_timeout (Integerwert)
Der citus.node_connection_timeout
-GUC legt die maximale Dauer (in Millisekunden) für das Warten auf die Verbindungsherstellung fest. Azure Cosmos DB for PostgreSQL löst einen Fehler aus, wenn das Timeout abläuft, bevor mindestens eine Workerverbindung hergestellt wurde. Dieser GUC wirkt sich auf Verbindungen zwischen dem Koordinator und Workern sowie Workern untereinander aus.
- Standardwert: 5 Sekunden
- Minimum: 10 Millisekunden
- Maximum: eine Stunde
-- set to 30 seconds
ALTER DATABASE foo
SET citus.node_connection_timeout = 30000;
citus.log_remote_commands (boolescher Wert)
Protokolliert alle Befehle, die der Koordinatorknoten an Workerknoten sendet. Beispiel:
-- reveal the per-shard queries behind the scenes
SET citus.log_remote_commands TO on;
-- run a query on distributed table "github_users"
SELECT count(*) FROM github_users;
Die Ausgabe zeigt aufgrund der einzelnen count(*)
-Abfrage für den Koordinatorknoten mehrere Abfragen an, die für Worker ausgeführt werden.
NOTICE: issuing SELECT count(*) AS count FROM public.github_events_102040 github_events WHERE true
DETAIL: on server citus@private-c.demo.postgres.database.azure.com:5432 connectionId: 1
NOTICE: issuing SELECT count(*) AS count FROM public.github_events_102041 github_events WHERE true
DETAIL: on server citus@private-c.demo.postgres.database.azure.com:5432 connectionId: 1
NOTICE: issuing SELECT count(*) AS count FROM public.github_events_102042 github_events WHERE true
DETAIL: on server citus@private-c.demo.postgres.database.azure.com:5432 connectionId: 1
... etc, one for each of the 32 shards
citus.show_shards_for_app_name_prefixes (Text)
Standardmäßig blendet Azure Cosmos DB for PostgreSQL Shards aus der Liste der Tabellen aus, die PostgreSQL an SQL-Clients übergibt. Dies geschieht, da es mehrere Shards pro verteilter Tabelle gibt, und die Shards können vom SQL-Client ablenken.
Der citus.show_shards_for_app_name_prefixes
-GUC ermöglicht die Anzeige von Shards für ausgewählte Clients, die sie anzeigen möchten. Der Standardwert ist ''.
-- show shards to psql only (hide in other clients, like pgAdmin)
SET citus.show_shards_for_app_name_prefixes TO 'psql';
-- also accepts a comma separated list
SET citus.show_shards_for_app_name_prefixes TO 'psql,pg_dump';
Das Ausblenden von Shards kann vollständig mit citus.override_table_visibility deaktiviert werden.
citus.override_table_visibility (boolescher Wert)
Bestimmt, ob citus.show_shards_for_app_name_prefixes aktiv ist. Der Standardwert ist ‚true‘. Wenn dieser Wert auf ‚false‘ festgelegt ist, sind Shards für alle Clientanwendungen sichtbar.
citus.use_citus_managed_tables (boolescher Wert)
Zulassen, dass auf neue lokale Tabellen durch Abfragen auf Workerknoten zugegriffen werden kann. Fügt alle neu erstellten Tabellen zu Citus-Metadaten hinzu, wenn diese aktiviert sind. Der Standardwert ist ‚false‘.
citus.rebalancer_by_disk_size_base_cost (integer)
Durch Verwendung der Strategie „by_disk_size“ zum erneuten Ausgleich erhält jede Shardgruppe diese Kosten in Bytes, die zur tatsächlichen Datenträgergröße hinzukommen. Dieser Wert wird verwendet, um zu vermeiden, dass ein schlechter Saldo entsteht, wenn in einigen Shards wenige Daten vorhanden sind. Die Annahme besteht darin, dass selbst leere Shards aufgrund der Parallelität und des voraussichtlichen künftigen Wachstums von leeren Shardgruppen mit einigen Kosten verbunden sind.
Der Standardwert ist 100MB
.
Abfragestatistik
citus.stat_statements_purge_interval (Integerwert)
Legt die Häufigkeit fest, mit der der Wartungdaemon Datensätze aus citus_stat_statements entfernt, für die in pg_stat_statements
keine Übereinstimmung vorliegt. Mit diesem Konfigurationswert wird das Zeitintervall zwischen Bereinigungen in Sekunden festgelegt. Der Standardwert ist 10. Der Wert 0 deaktiviert Bereinigungen.
SET citus.stat_statements_purge_interval TO 5;
Dieser Parameter ist für den Koordinator wirksam und kann zur Laufzeit geändert werden.
citus.stat_statements_max (Integerwert)
Die maximale Anzahl von Zeilen,die in citus_stat_statements
gespeichert werden. Der Standardwert ist 50000 und kann in einen beliebigen Wert im Bereich von 1000 bis 10000000 geändert werden. Jede Zeile benötigt 140 Byte Speicher, sodass das Festlegen von stat_statements_max
auf den maximal zulässigen Wert von 10 Millionen 1,4 GB Speicher verbraucht.
Das Ändern dieser GUC wird erst wirksam, wenn PostgreSQL neu gestartet wird.
citus.stat_statements_track (Enumeration)
Das Aufzeichnen von Statistiken für citus_stat_statements
erfordert zusätzliche CPU-Ressourcen.
Wenn die Datenbank unter Last gerät, kann der Administrator Anweisungsnachverfolgung deaktivieren, indem er citus.stat_statements_track
auf none
festlegt.
- all: (Standardeinstellung) Alle Anweisungen werden nachverfolgt.
- none: Deaktivieren der Nachverfolgung.
citus.stat_tenants_untracked_sample_rate
Samplingrate für neue Mandanten in citus_stat_tenants
. Die Rate kann zwischen 0.0
und 1.0
liegen. Der Standardwert ist 1.0
, was bedeutet, dass Stichproben von 100 % der Abfragen nicht verfolgter Mandanten genommen werden. Das Festlegen auf einen niedrigeren Wert bedeutet, dass bei bereits verfolgten Mandanten Stichproben von 100 % der Abfragen genommen werden, während bei derzeit nicht verfolgten Mandanten nur Stichproben zur angegebenen Rate genommen werden.
Laden von Daten
citus.multi_shard_commit_protocol (Enumeration)
Legt das Commitprotokoll fest, das beim Ausführen von COPY für eine Tabelle mit Hashverteilung verwendet werden soll. Bei jeder einzelnen Shardplatzierung wird COPY in einem Transaktionsblock ausgeführt, um sicherzustellen, dass keine Daten erfasst werden, wenn während des Kopiervorgangs ein Fehler auftritt. Es gibt jedoch einen bestimmten Fehlerfall, bei dem COPY bei allen Platzierungsvorgängen erfolgreich ist, aber vor dem Commit aller Transaktionen tritt ein Fehler (Hardwarefehler) auf. Dieser Parameter kann verwendet werden, um in diesem Fall Datenverluste zu verhindern, indem zwischen den folgenden Commitprotokollen ausgewählt wird:
- 2pc: (Standardwert) Die Transaktionen, bei denen COPY für die Shardplatzierungen ausgeführt wird, werden zuerst mit einem Zweiphasencommit von PostgreSQL vorbereitet und dann committet. Fehlgeschlagene Commits können mithilfe von COMMIT PREPARED bzw. ROLLBACK PREPARED manuell wiederhergestellt oder abgebrochen werden. Bei der Verwendung von 2pc sollte der Wert von max_prepared_transactions für alle Worker erhöht werden (in der Regel auf denselben Wert wie max_connections).
- 1pc: Die Transaktionen, bei denen für die Shardplatzierung COPY ausgeführt wird, werden in einer Runde committet. Daten gehen möglicherweise verloren, wenn ein Commit fehlschlägt, nachdem COPY für alle Platzierungen erfolgreich war (selten).
citus.shard_replication_factor (Integerwert)
Legt den Replikationsfaktor für Shards fest, d. h. die Anzahl der Knoten, auf denen Shards platziert werden, und der Standardwert ist 1. Dieser Parameter kann zur Laufzeit festgelegt werden und ist für den Koordinator gültig. Der ideale Wert für diesen Parameter hängt von der Größe des Clusters und der Rate der Knotenfehler ab. Beispielsweise können Sie diesen Replikationsfaktor erhöhen, wenn Sie große Cluster ausführen und Knotenfehler häufiger beobachtet werden.
Planerkonfiguration
citus.local_table_join_policy (Enumeration)
Dieser GUC bestimmt, wie Azure Cosmos DB for PostgreSQL Daten bei einem Join zwischen lokalen und verteilten Tabellen verschiebt. Das Anpassen der Joinrichtlinie kann dazu beitragen, die Datenmenge zu reduzieren, die zwischen Workerknoten gesendet wird.
Azure Cosmos DB for PostgreSQL sendet die lokalen oder verteilten Tabellen nach Bedarf an Knoten, um die Verknüpfung zu unterstützen. Das Kopieren von Tabellendaten wird als „Konvertierung“ bezeichnet. Wenn eine lokale Tabelle konvertiert wird, wird sie an alle Worker gesendet, die ihre Daten zum Ausführen der Verknüpfung benötigen. Wenn eine verteilte Tabelle konvertiert wird, wird sie im Koordinator gesammelt, um die Verknüpfung zu unterstützen. Der Azure Cosmos DB for PostgreSQL-Planer sendet bei einer Konvertierung nur die erforderlichen Zeilen.
Es stehen vier Modi zur Verfügung, um die Konvertierungseinstellung auszudrücken:
- auto: (Standard) Azure Cosmos DB for PostgreSQL konvertiert entweder alle lokalen oder alle verteilten Tabellen, um Verknüpfungen lokaler und verteilter Tabellen zu unterstützen. Azure Cosmos DB for PostgreSQL entscheidet mithilfe einer Heuristik, für welche die Konvertierung erfolgt. Verteilte Tabellen werden konvertiert, wenn sie mithilfe eines konstanten Filters für einen eindeutigen Index (z. B. einem Primärschlüssel) verknüpft werden. Durch die Konvertierung wird sichergestellt, dass weniger Daten zwischen Workern verschoben werden.
- never: Azure Cosmos DB for PostgreSQL erlaubt keine Verknüpfungen zwischen lokalen und verteilten Tabellen.
- prefer-local: Azure Cosmos DB for PostgreSQL bevorzugt die Konvertierung lokaler Tabellen zur Unterstützung von Verknüpfungen lokaler und verteilter Tabellen.
- prefer-distributed: Azure Cosmos DB for PostgreSQL bevorzugt die Konvertierung verteilter Tabellen zur Unterstützung von Verknüpfungen lokaler und verteilter Tabellen. Wenn die verteilten Tabellen sehr groß sind, kann die Verwendung dieser Option dazu führen, dass viele Daten zwischen Workern verschoben werden.
Angenommen, es handelt sich bei citus_table
um eine verteilte Tabelle, die von der Spalte x
verteilt wird, und postgres_table
ist eine lokale Tabelle:
CREATE TABLE citus_table(x int primary key, y int);
SELECT create_distributed_table('citus_table', 'x');
CREATE TABLE postgres_table(x int, y int);
-- even though the join is on primary key, there isn't a constant filter
-- hence postgres_table will be sent to worker nodes to support the join
SELECT * FROM citus_table JOIN postgres_table USING (x);
-- there is a constant filter on a primary key, hence the filtered row
-- from the distributed table will be pulled to coordinator to support the join
SELECT * FROM citus_table JOIN postgres_table USING (x) WHERE citus_table.x = 10;
SET citus.local_table_join_policy to 'prefer-distributed';
-- since we prefer distributed tables, citus_table will be pulled to coordinator
-- to support the join. Note that citus_table can be huge.
SELECT * FROM citus_table JOIN postgres_table USING (x);
SET citus.local_table_join_policy to 'prefer-local';
-- even though there is a constant filter on primary key for citus_table
-- postgres_table will be sent to necessary workers because we are using 'prefer-local'.
SELECT * FROM citus_table JOIN postgres_table USING (x) WHERE citus_table.x = 10;
citus.limit_clause_row_fetch_count (Integerwert)
Legt die Anzahl der Zeilen fest, die pro Task für die Optimierung der limit-Klausel abgerufen werden. In einigen Fällen müssen SELECT-Abfragen mit Limit-Klauseln möglicherweise alle Zeilen aus jedem Task abrufen, um Ergebnisse zu generieren. In diesen Fällen, in denen eine Näherung zu sinnvollen Ergebnissen führen würde, legt dieser Konfigurationswert die Anzahl der Zeilen fest, die aus jedem Shard abgerufen werden sollen. Limit-Näherungen sind standardmäßig deaktiviert, und dieser Parameter ist auf -1 festgelegt. Dieser Wert kann zur Laufzeit festgelegt werden und ist für den Koordinator gültig.
citus.count_distinct_error_rate (Gleitkommawert)
Azure Cosmos DB for PostgreSQL kann die count(distinct)-Näherung mithilfe der postgresql-hll-Erweiterung berechnen. Mit diesem Konfigurationseintrag wird die gewünschte Fehlerrate beim Berechnen von count(distinct) festgelegt. 0,0 ist die Standardeinstellung und deaktiviert Näherungswerte für count(distinct). 1,0 bietet keine Garantie bezüglich der Genauigkeit der Ergebnisse. Es wird empfohlen, diesen Parameter auf 0,005 festzulegen, um optimale Ergebnisse zu erzielen. Dieser Wert kann zur Laufzeit festgelegt werden und ist für den Koordinator gültig.
citus.task_assignment_policy (Enumeration)
Hinweis
Dieser GUC ist nur anwendbar, wenn shard_replication_factor größer als 1 ist, oder für Abfragen für reference_tables.
Legt die Richtlinie fest, die beim Zuweisen von Tasks an Worker verwendet wird. Der Koordinator weist Workern auf der Grundlage von Shardspeicherorten Tasks zu. Dieser Konfigurationswert gibt die Richtlinie an, die bei diesen Zuweisungen verwendet werden soll. Derzeit gibt es drei mögliche Taskzuweisungsrichtlinien, die verwendet werden können.
- greedy: Die greedy-Richtlinie ist die Standardeinstellung und zielt darauf ab, Tasks gleichmäßig auf Worker zu verteilen.
- round-robin: Die round-robin-Richtlinie weist Workern Tasks in einem Roundrobinverfahren zu, das ein Rotationsprinzip verwendet. Diese Richtlinie ermöglicht eine bessere Clusterauslastung, wenn die Anzahl der Shards für eine Tabelle im Vergleich zur Anzahl der Worker gering ist.
- first-replica: Die first-replica-Richtlinie weist Tasks auf der Grundlage der Einfügungsreihenfolge der Platzierungen (Replikate) für die Shards zu. Anders ausgedrückt: Die Fragmentabfrage für einen Shard wird dem Worker zugewiesen, der über das erste Replikat dieses Shards verfügt. Mit dieser Methode haben Sie starke Garantien dafür, welche Shards auf welchen Knoten verwendet werden (d. h. stärkere Garantien für die Speicherresidenz).
Dieser Parameter kann zur Laufzeit festgelegt werden und ist für den Koordinator gültig.
citus.enable_non_colocated_router_query_pushdown (boolean)
Aktiviert den Router Planner für die Abfragen, die auf nicht zusammengestellte verteilte Tabellen verweisen.
Der Router Planner ist nur für Abfragen aktiviert, die auf verteilte Tabellen verweisen, da andernfalls keine Shards auf demselben Knoten vorhanden sind. Das Aktivieren dieses Flags ermöglicht die Optimierung von Abfragen, die auf solche Tabellen verweisen, aber die Abfrage funktioniert möglicherweise nicht, nachdem die Shards neu ausgeglichen wurden oder die Shardanzahl dieser Tabellen geändert wurde.
Der Standardwert ist off
.
Übertragung von Zwischendaten
citus.max_intermediate_result_size (Integerwert)
Die maximale Größe in KB von Zwischenergebnissen für CTEs, die zur Ausführung nicht auf Workerknoten gepusht werden können, und für komplexe Unterabfragen. Der Standardwert ist 1 GB. Der Wert -1 bedeutet, dass kein Grenzwert gilt. Abfragen, die den Grenzwert überschreiten, werden abgebrochen und führen zu einer Fehlermeldung.
DDL
citus.enable_schema_based_sharding
Wenn der Parameter auf ON
festgelegt ist, werden alle erstellten Schemas standardmäßig verteilt. Verteilte Schemas werden automatisch einzelnen Zusammenstellungsgruppen zugeordnet, sodass die in diesen Schemas erstellten Tabellen in zusammengestellte verteilte Tabellen ohne Shardschlüssel konvertiert werden. Diese Einstellung kann für einzelne Sitzungen geändert werden.
Ein Beispiel für die Verwendung dieses GUC finden Sie unter So entwerfen Sie einen Microservice.
Executor-Konfiguration
Allgemein
citus.all_modifications_commutative
Azure Cosmos DB for PostgreSQL erzwingt Kommutativitätsregeln und ruft geeignete Sperren für Änderungsvorgänge ab, um die Richtigkeit des Verhaltens zu gewährleisten. Beispielsweise wird davon ausgegangen, dass eine INSERT-Anweisung mit einer anderen INSERT-Anweisung, aber nicht mit einer UPDATE- oder DELETE-Anweisung Kommutativität aufweist. Entsprechend wird auch davon ausgegangen, dass eine UPDATE- oder DELETE-Anweisung keine Kommutativität mit einer anderen UPDATE- oder DELETE-Anweisung verwendet. Diese Vorsichtsmaßnahme hat zur Folge, dass Azure Cosmos DB for PostgreSQL für UPDATE- und DELETE-Vorgänge stärkere Sperren erwerben muss.
Wenn Sie über UPDATE-Anweisungen verfügen, die mit INSERT- oder anderen UPDATE-Vorgängen Kommutativität verwenden, können Sie diese Kommutativitätsannahmen durch Festlegen dieses Parameters auf TRUE lockern. Wenn dieser Parameter auf TRUE festgelegt ist, werden alle Befehle als kommutativ angesehen und beanspruchen eine gemeinsame Sperre, was den Gesamtdurchsatz verbessern kann. Dieser Parameter kann zur Laufzeit festgelegt werden und ist für den Koordinator gültig.
citus.remote_task_check_interval (Integerwert)
Legt die Häufigkeit fest, mit der Azure Cosmos DB for PostgreSQL die Status von Aufträgen überprüft, die vom taskt-racker-Executor verwaltet werden. Der Standardwert lautet 10 ms. Der Koordinator weist Workern Tasks zu und überprüft sie regelmäßig hinsichtlich des Fortschritts der einzelnen Tasks. Mit diesem Konfigurationswert wird das Zeitintervall zwischen zwei aufeinanderfolgenden Überprüfungen festgelegt. Dieser Parameter ist für den Koordinator wirksam und kann zur Laufzeit festgelegt werden.
citus.task_executor_type (Enumeration)
Azure Cosmos DB for PostgreSQL verfügt über drei Ausführungstypen für die Ausführung verteilter SELECT-Abfragen. Der gewünschte Executor kann durch Festlegen dieses Konfigurationsparameters ausgewählt werden. Die folgenden Werte sind für diesen Parameter zulässig:
- adaptive: Der Standardwert. Er eignet sich optimal für schnelle Antworten auf Abfragen, die Aggregationen und Joins mit Colocation umfassen, die auf mehrere Shards verteilt sind.
- task-tracker: Der task-tracker-Executor eignet sich gut für zeitintensive komplexe Abfragen, bei denen Daten über mehrere Workerknoten hinweg gemischt werden müssen, sowie für effiziente Ressourcenverwaltung.
- real-time: (veraltet) Dient einem ähnlichen Zweck wie der adaptive Executor, ist aber weniger flexibel und kann zu mehr Verbindungsfehlern auf Workerknoten führen.
Dieser Parameter kann zur Laufzeit festgelegt werden und ist für den Koordinator gültig.
citus.multi_task_query_log_level (Enumeration) {#multi_task_logging}
Legt einen Protokolliergrad für jede Abfrage fest, die mehrere Tasks generiert (d. h., die mehr als einen Shard betrifft). Die Protokollierung ist während der Migration einer mehrinstanzenfähigen Anwendung nützlich, da Sie für solche Abfragen einen Fehler oder eine Warnung anzeigen können, um diese zu ermitteln und ihnen einen tenant_id-Filter hinzuzufügen. Dieser Parameter kann zur Laufzeit festgelegt werden und ist für den Koordinator gültig. Der Standardwert für diesen Parameter ist „off“.
Die unterstützten Werte für diese Enumeration lauten:
- off: Deaktiviert die Protokollierung von Abfragen, die mehrere Tasks generieren (d. h. mehrere Shards umfassen).
- debug: Protokolliert die Anweisung mit dem DEBUG-Schweregrad.
- log: Protokolliert die Anweisung mit dem LOG-Schweregrad. Die Protokollzeile enthält die SQL-Abfrage, die ausgeführt wurde.
- notice: Protokolliert die Anweisung mit dem NOTICE-Schweregrad.
- warning: Protokolliert die Anweisung mit dem WARNING-Schweregrad.
- error: Protokolliert die Anweisung mit dem ERROR-Schweregrad.
Es könnte nützlich sein, error
während der Entwicklungstests und einen niedrigeren Protokolliergrad wie log
während der tatsächlichen Bereitstellung in der Produktion zu verwenden.
Wenn Sie log
auswählen, werden Abfragen für mehrere Tasks in den Datenbankprotokollen angezeigt. Dabei wird die Abfrage selbst nach „STATEMENT“ angezeigt.
LOG: multi-task query about to be executed
HINT: Queries are split to multiple tasks if they have to be split into several queries on the workers.
STATEMENT: select * from foo;
citus.propagate_set_commands (Enumeration)
Bestimmt, welche SET-Befehle vom Koordinator an die Worker propagiert werden. Der Standardwert für diesen Parameter ist „none“.
Die unterstützten Werte sind:
- none: Es werden keine SET-Befehle propagiert.
- local: Nur SET LOCAL-Befehle werden propagiert.
citus.create_object_propagation (Enumeration)
Steuert das Verhalten von CREATE-Anweisungen in Transaktionen für unterstützte Objekte.
Wenn Objekte in einem Transaktionsblock mit mehreren Anweisungen erstellt werden, wechselt Azure Cosmos DB for PostgreSQL in den sequenziellen Modus, um sicherzustellen, dass erstellte Objekte für spätere Anweisungen auf Shards sichtbar sind. Der Wechsel zum sequenziellen Modus ist jedoch nicht immer wünschenswert. Durch das Überschreiben dieses Verhaltens kann der Benutzer die Leistung für die vollständige Transaktionskonsistenz bei der Erstellung neuer Objekte abhandeln.
Der Standardwert für diesen Parameter lautet ‚immediate‘.
Die unterstützten Werte sind:
- immediate: löst Fehler in Transaktionen aus, bei denen parallele Vorgänge wie create_distributed_table vor einem Versuch von CREATE TYPE auftreten.
- automatic: stellt die Erstellung von Typen beim Freigeben einer Transaktion mit einem parallelen Vorgang für verteilte Tabellen zurück. Möglicherweise gibt es einige Inkonsistenzen, zwischen denen Datenbankobjekte auf verschiedenen Knoten vorhanden sind.
- deferred: kehrt zum Vor-11.0-Verhalten zurück, das wie automatisch, aber mit anderen subtilen Eckfällen aussieht. Wir empfehlen die automatische Einstellung über ‚deferred‘, es sei denn, Sie benötigen eine echte Abwärtskompatibilität.
Ein Beispiel für diese GUC-Aktion finden Sie unter Typverteilung.
citus.enable_repartition_joins (boolescher Wert)
Normalerweise schlägt der Versuch, eine Verknüpfung einer Neupartitionierung mit dem adaptiven Executor durchzuführen, mit einer Fehlermeldung fehl. Wenn Sie jedoch citus.enable_repartition_joins
auf TRUE festlegen, kann Azure Cosmos DB for PostgreSQL vorübergehend in den task-tracker-Executor wechseln, um den Join auszuführen. Der Standardwert ist „FALSE“.
citus.enable_repartitioned_insert_select (boolescher Wert)
Standardmäßig versucht eine Anweisung INSERT INTO... Eine SELECT-Anweisung, die nicht nach unten gepusht werden kann, versucht Zeilen aus der SELECT-Anweisung neu zu partitionieren und zum Einfügen zwischen Workern zu übertragen. Wenn die Zieltabelle jedoch zu viele Shards enthält, funktioniert die Neupartitionierung möglicherweise nicht gut. Der Mehraufwand für die Verarbeitung der Shardintervalle beim Bestimmen der Partitionierung der Ergebnisse ist zu groß.
Die Neupartitionierung kann manuell deaktiviert werden, indem citus.enable_repartitioned_insert_select
auf FALSE festgelegt wird.
citus.enable_binary_protocol (boolescher Wert)
Durch Festlegen dieses Parameters auf TRUE wird der Koordinatorknoten angewiesen, das binäre Serialisierungsformat von PostgreSQL (falls zutreffend) zum Übertragen von Daten mit Workern zu verwenden. Einige Spaltentypen unterstützen keine binäre Serialisierung.
Die Aktivierung dieses Parameters ist vor allem dann sinnvoll, wenn die Worker große Datenmengen zurückgeben müssen. Beispiele: Es werden viele Zeilen angefordert, die Zeilen weisen viele Spalten auf oder verwenden breite Typen wie hll
aus der postgresql-hll-Erweiterung.
Der Standardwert ist true
. Bei Festlegung auf false
werden alle Ergebnisse im Textformat codiert und übertragen.
citus.max_adaptive_executor_pool_size (Integerwert)
Max_adaptive_executor_pool_size schränkt Workerverbindungen aus der aktuellen Sitzung ein. Dieser GUC ist für Folgendes nützlich:
- Verhindern, dass ein einzelnes Back-End alle Workerressourcen erhält
- Bereitstellen von Prioritätsverwaltung: Festlegen von Sitzungen mit niedriger Priorität mit max_adaptive_executor_pool_size und Sitzungen mit hoher Priorität mit höheren Werten
Der Standardwert ist 16.
citus.executor_slow_start_interval (Integerwert)
Wartezeit in Millisekunden zwischen dem Öffnen von Verbindungen mit demselben Workerknoten.
Wenn die einzelnen Tasks einer Abfrage mit mehreren Shards wenig Zeit benötigen, können sie häufig über eine einzelne (oft bereits zwischengespeicherte) Verbindung abgeschlossen werden. Um zu vermeiden, dass redundant weitere Verbindungen geöffnet werden, wartet der Executor zwischen Verbindungsversuchen die konfigurierte Anzahl von Millisekunden. Am Ende des Intervalls erhöht sich die Anzahl der Verbindungen, die beim nächsten Mal geöffnet werden dürfen.
Bei langen Abfragen (die > 500 ms dauern) kann ein langsamer Start die Wartezeit erhöhen, bei kurzen Abfragen ist dies jedoch schneller. Der Standardwert ist 10 ms.
citus.max_cached_conns_per_worker (Integerwert)
Jedes Back-End öffnet Verbindungen mit den Workern, um die Shards abzufragen. Am Ende der Transaktion bleibt die konfigurierte Anzahl von Verbindungen geöffnet, um nachfolgende Befehle zu beschleunigen. Eine Erhöhung dieses Werts verringert die Wartezeit von Abfragen mit mehreren Shards, erhöht aber auch den Mehraufwand für die Worker.
Der Standardwert ist 1. Ein größerer Wert wie z. B. 2 kann für Cluster hilfreich sein, die eine kleine Anzahl gleichzeitiger Sitzungen verwenden, aber es ist nicht sinnvoll, einen noch größeren Wert zu wählen (z. B. wäre 16 zu groß).
citus.force_max_query_parallelization (boolescher Wert)
Simuliert den veralteten und jetzt nicht mehr vorhandenen Echtzeitexecutor. Dieser Parameter wird verwendet, um so viele Verbindungen wie möglich zu öffnen, um die Abfrageparallelisierung zu maximieren.
Wenn dieser GUC aktiviert ist, zwingt Azure Cosmos DB for PostgreSQL den adaptiven Executor, beim Ausführen einer parallelen verteilten Abfrage so viele Verbindungen wie möglich zu verwenden. Wenn diese Option nicht aktiviert ist, kann der Executor weniger Verbindungen verwenden, um den Gesamtdurchsatz der Abfrageausführung zu optimieren. Intern führt das Festlegen auf true
dazu, dass ein Connector pro Aufgabe verwendet wird.
Dieser Parameter ist z. B. bei einer Transaktion sinnvoll, deren erste Abfrage einfach ist und nur wenige Verbindungen erfordert, während eine nachfolgende Abfrage von mehr Verbindungen profitieren würde. Azure Cosmos DB for PostgreSQL entscheidet auf der Grundlage der ersten Anweisung, wie viele Verbindungen in einer Transaktion verwendet werden sollen. Dies kann andere Abfragen drosseln, es sei denn, der GUC wird verwendet, um einen Hinweis bereitzustellen.
BEGIN;
-- add this hint
SET citus.force_max_query_parallelization TO ON;
-- a lightweight query that doesn't require many connections
SELECT count(*) FROM table WHERE filter = x;
-- a query that benefits from more connections, and can obtain
-- them since we forced max parallelization above
SELECT ... very .. complex .. SQL;
COMMIT;
Der Standardwert ist „FALSE“.
task-tracker-Executor-Konfiguration
citus.task_tracker_delay (Integerwert)
Mit diesem Parameter wird der Ruhezustand von task-tracker zwischen Taskverwaltungsrunden festgelegt. Der Standardwert ist 200 ms. Der task-tracker-Prozess wird regelmäßig aktiviert, durchläuft alle ihm zugewiesenen Aufgaben und plant diese Aufgaben und führt sie aus. Anschließend geht task-tracker für einen bestimmten Zeitraum in den Ruhezustand über, bevor er diese Tasks erneut durchläuft. Dieser Konfigurationswert bestimmt die Länge dieses Ruhezeitraums. Dieser Parameter ist für die Worker gültig und muss in der Datei „postgresql.conf“ geändert werden. Nachdem Sie die Konfigurationsdatei bearbeitet haben, können Benutzer ein SIGHUP-Signal senden oder den Server neu starten, damit die Änderung wirksam wird.
Der Wert dieses Parameters kann verringert werden, um die Verzögerung zu verkürzen, die durch den task-tracker-Executor verursacht wird, indem die Zeitspanne zwischen den Verwaltungsrunden reduziert wird. Das Verringern der Verzögerung ist in Fällen hilfreich, in denen die Shardabfragen kurz sind, sodass ihr Status regelmäßig aktualisiert wird.
citus.max_assign_task_batch_size (Integerwert)
Der task-tracker-Executor für den Koordinator weist dem Daemon für die Worker synchron Tasks in Batches zu. Dieser Parameter legt die maximale Anzahl von Tasks fest, die in einem einzelnen Batch zugewiesen werden sollen. Die Auswahl einer größeren Batchgröße ermöglicht eine schnellere Taskzuweisung. Wenn die Anzahl der Worker jedoch groß ist, kann es länger dauern, bis alle Worker Tasks erhalten. Dieser Parameter kann zur Laufzeit festgelegt werden und ist für den Koordinator gültig.
citus.max_running_tasks_per_node (Integerwert)
Der task-tracker-Prozess plant und führt die ihm zugewiesenen Tasks nach Bedarf aus. Mit diesem Konfigurationswert wird die maximale Anzahl der gleichzeitig auf einem Knoten auszuführenden Tasks festgelegt. Der Standardwert ist 8.
Durch den Grenzwert wird sichergestellt, dass nicht zu viele Tasks gleichzeitig auf den Datenträger zugreifen, und es werden E/A-Konflikte des Datenträgers vermieden. Wenn Ihre Abfragen aus dem Arbeitsspeicher oder von SSDs bereitgestellt werden, können Sie max_running_tasks_per_node ohne große Bedenken erhöhen.
citus.partition_buffer_size (Integerwert)
Legt die für Partitionsvorgänge zu verwendende Puffergröße fest. Der Standardwert beträgt 8 MB. Azure Cosmos DB for PostgreSQL ermöglicht die Neupartitionierung von Tabellendaten in mehrere Dateien, wenn zwei große Tabellen verknüpft werden. Nachdem dieser Partitionspuffer mit Daten aufgefüllt wurde, werden die neu partitionierten Daten in Dateien auf dem Datenträger geleert. Dieser Konfigurationseintrag kann zur Laufzeit festgelegt werden und ist für die Worker wirksam.
Erläutern der Ausgabe
citus.explain_all_tasks (boolescher Wert)
Standardmäßig zeigt Azure Cosmos DB for PostgreSQL die Ausgabe eines einzelnen, beliebigen Tasks an, wenn EXPLAIN für eine verteilte Abfrage ausgeführt wird. In den meisten Fällen ist die Ausgabe der Erklärung bei allen Aufgaben ähnlich. Gelegentlich werden einige der Aufgaben anders geplant oder weisen eine viel höhere Ausführungszeit auf. In diesen Fällen kann es hilfreich sein, diesen Parameter zu aktivieren, anschließend umfasst die Ausgabe von EXPLAIN alle Aufgaben. Wenn Sie alle Tasks erläutern, nimmt EXPLAIN möglicherweise längere Zeit in Anspruch.
citus.explain_analyze_sort_method (Enumeration)
Bestimmt die Sortiermethode der Tasks in der Ausgabe von EXPLAIN ANALYZE. Der Standardwert von citus.explain_analyze_sort_method
ist execution-time
.
Die unterstützten Werte sind:
- execution-time: Sortiert nach Ausführungszeit.
- taskId: Sortiert nach Task-ID.
Verwaltete PgBouncer-Parameter
Die folgenden verwalteten PgBouncer-Parameter können auf einem einzelnen Knoten oder Koordinator konfiguriert werden.
Parametername | BESCHREIBUNG | Standard |
---|---|---|
pgbouncer.default_pool_size | Setzen Sie diesen Parameterwert auf die Anzahl der Verbindungen pro Benutzer/Datenbankpaar. | 295 |
pgbouncer.ignore_startup_parameters | Durch Trennzeichen getrennte Liste von Parametern, die PgBouncer ignorieren soll. Beispielsweise können Sie den Parameter extra_float_digits durch PgBouncer ignorieren lassen. Einige Parameter sind zulässig, alle anderen lösen einen Fehler aus. Dies ist erforderlich, um die übereifrige Java Database Connectivity (JDBC) zu tolerieren, die im Startpaket „extra_float_digits=2“ ohne Bedingung festlegen möchte. Verwenden Sie diese Option, wenn die von Ihnen verwendete Bibliothek Fehler wie pq: unsupported startup parameter: extra_float_digits meldet. |
extra_float_digits, ssl_renegotiation_limit |
pgBouncer.max_client_conn | Legen Sie diesen Parameterwert auf die höchste Anzahl von Clientverbindungen mit PgBouncer fest, die Sie unterstützen möchten. | 2000 |
pgBouncer.min_pool_size | Fügen Sie dem Pool weitere Serververbindungen hinzu, wenn diese Zahl unterschritten wird. | 0 (Deaktiviert) |
pgBouncer.pool_mode | Setzen Sie diesen Parameterwert für Transaktions-Pooling auf TRANSACTION (dies ist die empfohlene Einstellung für die meisten Workloads). | TRANSACTION |
pgbouncer.query_wait_timeout | Abfragen dürfen maximal diese Zeit (in Sekunden) auf die Ausführung warten. Wenn die Abfrage während dieser Zeit keinem Server zugewiesen wurde, wird die Verbindung mit dem Client getrennt. | 20 s |
pgbouncer.server_idle_timeout | Wenn eine Serververbindung mehr als so viele Sekunden im Leerlauf war, wird sie geschlossen. Wenn 0, dann ist dieses Timeout deaktiviert. | 60s |
PostgreSQL-Parameter
- DateStyle: Legt das Anzeigeformat für Datums- und Uhrzeitwerte fest
- IntervalStyle: Legt das Anzeigeformat für Intervallwerte fest
- TimeZone: Legt die Zeitzone für die Anzeige und Interpretation von Zeitstempeln fest
- application_name: Legt den Anwendungsnamen fest, der in Statistiken und Protokollen angegeben werden soll
- array_nulls: Ermöglicht die Eingabe von NULL-Elementen in Arrays
- autovacuum: Startet den Autovacuum-Teilprozess
- autovacuum_analyze_scale_factor: Anzahl der Tupeleinfügungen, -updates oder -löschungen vor der Analyse als Teil von „reltuples“
- autovacuum_analyze_threshold: Mindestanzahl von Tupeleinfügungen, -updates oder -löschungen vor der Analyse
- autovacuum_naptime: Standbyzeit zwischen Autovacuum-Ausführungen
- autovacuum_vacuum_cost_delay: Vacuum-Kostenverzögerung in Millisekunden für Autovacuum
- autovacuum_vacuum_cost_limit: Der vor dem Standby für Autovacuum verfügbare Vacuum-Kostenbetrag
- autovacuum_vacuum_scale_factor: Anzahl der Tupelupdates oder -löschungen vor dem Ausführen von Vacuum-Prozessen als Teil von „reltuples“
- autovacuum_vacuum_threshold: Mindestanzahl von Tupelupdates oder -löschungen vor dem Ausführen von Vacuum-Prozessen
- autovacuum_work_mem: Legt den maximalen Arbeitsspeicher zur Verwendung durch die einzelnen Autovacuum-Workerprozesse fest
- backend_flush_after: Anzahl der Seiten, nach denen zuvor durchgeführte Schreibvorgänge auf den Datenträger geleert werden
- backslash_quote: Legt fest, ob „'“ in Zeichenfolgenliteralen zulässig ist.
- bgwriter_delay: Standbyzeit für das Schreiben im Hintergrund zwischen zwei Runden
- bgwriter_flush_after: Anzahl der Seiten, nach denen zuvor durchgeführte Schreibvorgänge auf den Datenträger geleert werden
- bgwriter_lru_maxpages: Maximale Anzahl von Schreibvorgängen im Hintergrund bei LRU-Seiten, die pro Runde geleert werden
- bgwriter_lru_multiplier: Vielfaches der Freigabe des durchschnittlich genutzten Puffers pro Runde
- bytea_output: Legt das Ausgabeformat für bytea fest
- check_function_bodies: Prüft Funktionstexte beim Ausführen von CREATE FUNCTION
- checkpoint_completion_target: Zeit, die zum Leeren von leeren modifizierten Puffern während des Prüfpunkts aufgewendet wird, als Teil des Prüfpunktintervalls
- checkpoint_timeout: Legt die maximale Zeit zwischen automatischen WAL-Prüfpunkten fest
- checkpoint_warning: Aktiviert Warnungen, wenn Prüfpunktsegmente häufiger gefüllt werden
- client_encoding: Legt die Zeichensatzcodierung des Clients fest
- client_min_messages: Legt die Meldungsebenen fest, die an den Client gesendet werden
- commit_delay: Legt die Verzögerung zwischen einem Transaktionscommit und dem Leeren von WAL auf den Datenträger in Mikrosekunden fest
- commit_siblings: Legt die Mindestanzahl der gleichzeitig geöffneten Transaktionen vor dem Durchführen von „commit_delay“ fest
- constraint_exclusion: Ermöglicht dem Planer die Verwendung von Einschränkungen zur Optimierung von Abfragen
- cpu_index_tuple_cost: Legt die Kostenschätzung des Planers für die Verarbeitung der einzelnen Indexeinträge bei einem Indexscan fest
- cpu_operator_cost: Legt die Kostenschätzung des Planers für die Verarbeitung der einzelnen Operatoren oder Funktionsaufrufe fest
- cpu_tuple_cost: Legt die Kostenschätzung des Planers für die Verarbeitung der einzelnen Tupel (Zeilen) fest
- cursor_tuple_fraction – Legt die Schätzung des Planers für den Anteil der Zeilen eines Cursors fest, die abgerufen werden
- deadlock_timeout: Legt die Zeitspanne, die bei einer Sperre vor der Prüfung auf einen Deadlock gewartet werden soll, in Millisekunden fest
- debug_pretty_print: Fügt einen Einzug für Analyse- und Planstrukturanzeigen ein
- debug_print_parse: Protokolliert die Analysestruktur der einzelnen Abfragen
- debug_print_plan: Protokolliert den Ausführungsplan der einzelnen Abfragen
- debug_print_rewritten: Protokolliert die umgeschriebene Analysestruktur der einzelnen Abfragen
- default_statistics_target: Legt das Standardstatistikziel fest
- default_tablespace: Legt den Standardtabellenbereich zum Erstellen von Tabellen und Indizes fest
- default_text_search_config: Legt die Konfiguration für die Standardtextsuche fest
- default_transaction_deferrable: Legt den Standardstatus für die Verzögerbarkeit von neuen Transaktionen fest
- default_transaction_isolation: Legt die Transaktionsisolationsstufe für jede neue Transaktion fest
- default_transaction_read_only: Legt den Standardstatus für den Schreibschutz neuer Transaktionen fest
- default_with_oids: Erstellt neue Tabellen standardmäßig mit OIDs
- effective_cache_size: Legt die Annahme des Planers in Bezug auf die Größe des Datenträgercaches fest
- enable_bitmapscan: Ermöglicht dem Planer die Verwendung von Bitmapscanplänen
- enable_gathermerge: Ermöglicht dem Planer die Verwendung von Plänen zum Erfassen und Zusammenführen
- enable_hashagg: Ermöglicht dem Planer die Verwendung von Plänen für Hashaggregationen
- enable_hashjoin: Ermöglicht dem Planer die Verwendung von Hashjoinplänen
- enable_indexonlyscan: Ermöglicht dem Planer die Verwendung von Plänen zum ausschließlichen Scannen von Indizes
- enable_indexscan: Ermöglicht dem Planer die Verwendung von Plänen zum Scannen von Indizes
- enable_material: Ermöglicht dem Planer die Verwendung der Materialisierung
- enable_mergejoin: Ermöglicht dem Planer die Verwendung von Merge-Join-Plänen
- enable_nestloop: Ermöglicht dem Planer die Verwendung von Nested-Loop-Join-Plänen
- enable_seqscan: Ermöglicht dem Planer die Verwendung von Plänen für sequenzielle Scans
- enable_sort: Ermöglicht dem Planer die Verwendung von expliziten Schritten zum Sortieren
- enable_tidscan: Ermöglicht dem Planer die Verwendung von Plänen zum Scannen der Steuernummer
- escape_string_warning: Warnt vor Schrägstrich als Escapezeichen in normalen Zeichenfolgenliteralen
- exit_on_error: Beendet eine Sitzung bei einem Fehler
- extra_float_digits:Legt die Anzahl der Stellen fest, die für Gleitkommawerte angezeigt werden
- force_parallel_mode: Erzwingt die Verwendung von Funktionen zur parallelen Abfrage
- from_collapse_limit: Legt die Größe der FROM-Liste fest, ab der Unterabfragen nicht mehr reduziert werden
- geqo: Ermöglicht die Optimierung genetischer Abfragen
- geqo_effort: GEQO: Aufwand zum Festlegen der Standardeinstellung für andere GEQO-Parameter
- geqo_generations: GEQO: Anzahl der Iterationen des Algorithmus
- geqo_pool_size: GEQO: Anzahl der Individuen in einer Population
- geqo_seed: GEQO: Seed für die zufällige Auswahl von Pfaden
- geqo_selection_bias: GEQO: selektiver Druck innerhalb der Population
- geqo_threshold: Legt den Schwellenwert von FROM-Elementen fest, ab dem GEQO verwendet wird
- gin_fuzzy_search_limit: Legt das maximal zulässige Ergebnis für die exakte Suche durch GIN fest
- gin_pending_list_limit: Legt die maximale Größe der ausstehenden Liste für den GIN-Index fest
- idle_in_transaction_session_timeout: Legt die maximal zulässige Dauer für eine Transaktion im Leerlauf fest
- join_collapse_limit: Legt die Größe der FROM-Liste fest, ab der JOIN-Konstrukte nicht mehr vereinfacht werden
- lc_monetary: Legt das Gebietsschema für die Formatierung von Geldbeträgen fest
- lc_numeric: Legt das Gebietsschema für die Formatierung von Zahlen fest
- lo_compat_privileges: Ermöglicht den Abwärtskompatibilitätsmodus für Berechtigungsprüfungen bei großen Objekten
- lock_timeout: Legt die maximal zulässige Dauer für das Warten auf eine Sperre (in Millisekunden) fest. Mit 0 wird diese Option deaktiviert.
- log_autovacuum_min_duration – Legt die mindestens erforderliche Ausführungszeit fest, nach der autovacuum-Aktionen protokolliert werden
- log_connections: Protokolliert alle erfolgreichen Verbindungen
- log_destination: Legt das Ziel für die Ausgabe des Serverprotokolls fest
- log_disconnections: Protokolliert das Ende einer Sitzung und die Dauer
- log_duration: Protokolliert die Dauer aller ausgeführten SQL-Anweisungen
- log_error_verbosity: Legt die Ausführlichkeit von protokollierten Meldungen fest
- log_lock_waits: Protokolliert lange Wartezeiten für Sperren
- log_min_duration_statement – Legt die mindestens erforderliche Ausführungszeit (in Millisekunden) fest, ab der Anweisungen protokolliert werden. Mit -1 wird die Dauer von Protokollierungsanweisungen deaktiviert
- log_min_error_statement: Bewirkt, dass alle Anweisungen, die auf oder ab dieser Ebene einen Fehler verursachen, protokolliert werden
- log_min_messages: Legt die Meldungsebenen fest, die protokolliert werden
- log_replication_commands: Protokolliert alle Replikationsbefehle
- log_statement: Legt den Typ der protokollierten Anweisungen fest
- log_statement_stats: Schreibt für alle Abfragen eine kumulative Leistungsstatistik in das Serverprotokoll
- log_temp_files: Protokolliert die Verwendung von temporären Dateien, die größer als diese Zahl in Kilobyte sind
- maintenance_work_mem: Legt den maximalen Arbeitsspeicher fest, der für Wartungsvorgänge verwendet werden soll
- max_parallel_workers: Legt die maximale Anzahl von parallelen Workern fest, die gleichzeitig aktiv sein können
- max_parallel_workers_per_gather: Legt die maximale Anzahl von parallelen Prozessen pro Executorknoten fest
- max_pred_locks_per_page: Legt die maximale Anzahl von Tupeln mit gesperrtem Prädikat pro Seite fest
- max_pred_locks_per_relation: Legt die maximale Anzahl von Seiten und Tupeln mit gesperrtem Prädikat pro Beziehung fest
- max_standby_archive_delay: Legt die maximale Verzögerung vor dem Abbruch von Abfragen fest, wenn ein unmittelbar betriebsbereiter Standbyserver archivierte WAL-Daten verarbeitet
- max_standby_streaming_delay: Legt die maximale Verzögerung vor dem Abbruch von Abfragen fest, wenn ein unmittelbar betriebsbereiter Standbyserver gestreamte WAL-Daten verarbeitet
- max_sync_workers_per_subscription: Maximale Anzahl von Tabellensynchronisierungsworkern pro Abonnement
- max_wal_size: Legt die WAL-Größe fest, bei der ein Prüfpunkt ausgelöst wird
- min_parallel_index_scan_size: Legt die mindestens erforderliche Menge an Indexdaten für einen parallelen Scan fest
- min_wal_size: Legt die mindestens erforderliche Größe fest, auf die das WAL verkleinert werden kann
- operator_precedence_warning: Gibt eine Warnung für Konstrukte aus, deren Bedeutung sich seit PostgreSQL 9.4 geändert hat
- parallel_setup_cost: Legt die Kostenschätzung des Planers für das Starten von Workerprozessen für parallele Abfragen fest
- parallel_tuple_cost: Legt die Kostenschätzung des Planers für die Übergabe der einzelnen Tupeln (Zeilen) vom Worker an das Main-Back-End fest
- pg_stat_statements.save: Speichert „pg_stat_statements“-Statistiken beim Herunterfahren von Servern
- pg_stat_statements.track: Wählt aus, welche Anweisungen durch „pg_stat_statements“ verfolgt werden
- pg_stat_statements.track_utility: Wählt aus, ob Hilfsprogrammbefehle durch „pg_stat_statements“ verfolgt werden
- quote_all_identifiers: Gibt beim Erzeugen von SQL-Fragmenten alle Bezeichner an
- random_page_cost: Legt die Kostenschätzung des Planers für eine nicht sequenziell abgerufene Datenträgerseite fest
- row_security: Aktiviert die Zeilensicherheit
- search_path: Legt die Schemasuchreihenfolge für Namen fest, die nicht schemaqualifiziert sind
- seq_page_cost: Legt die Kostenschätzung des Planers für eine sequenziell abgerufene Datenträgerseite fest
- session_replication_role: Legt das Verhalten der Sitzung bei Triggern und Umschreibregeln fest
- standard_conforming_strings: Bewirkt, dass „...“-Zeichenfolgen umgekehrte Schrägstriche wörtlich behandeln
- statement_timeout: Legt die maximal zulässige Dauer einer Anweisung (in Millisekunden) fest. Mit 0 wird diese Option deaktiviert.
- synchronize_seqscans: Ermöglicht synchronisierte sequenzielle Scans
- synchronous_commit: Legt die Synchronisierungsstufe der aktuellen Transaktion fest
- tcp_keepalives_count: Maximale Anzahl von TCP-Keep-Alive-Neuübertragungen
- tcp_keepalives_idle: Zeit zwischen der Ausgabe von TCP-Keep-Alives
- tcp_keepalives_interval: Zeit zwischen TCP-Keep-Alive-Neuübertragungen
- temp_buffers:Legt die maximale Anzahl von temporären Puffern fest, die von den einzelnen Datenbanksitzungen verwendet werden
- temp_tablespaces: Legt die Tabellenbereiche zur Verwendung für temporäre Tabellen und Sortierungsdateien fest
- track_activities: Sammelt Informationen über die Ausführung von Befehlen
- track_counts: Sammelt Statistiken über Datenbankaktivitäten
- track_functions: Sammelt Statistiken über Datenbankaktivitäten auf Funktionsebene
- track_io_timing: Sammelt Zeitstatistiken für Datenbank-E/A-Aktivitäten
- transform_null_equals: Behandelt „expr=NULL“ wie „expr IS NULL“
- vacuum_cost_delay: Vacuum-Kostenverzögerung in Millisekunden
- vacuum_cost_limit: Der vor dem Standby verfügbare Vacuum-Kostenbetrag
- vacuum_cost_page_dirty: Vacuum-Kosten für eine durch Vacuum geänderte Seite
- vacuum_cost_page_hit: Vacuum-Kosten für eine im Puffercache gefundene Seite
- vacuum_cost_page_miss: Vacuum-Kosten für eine nicht im Puffercache gefundene Seite
- vacuum_defer_cleanup_age: Anzahl der Transaktionen, nach der eine VACUUM- und HOT-Bereinigung ggf. verzögert werden sollte
- vacuum_freeze_min_age: Mindestens erforderliches Alter, ab dem VACUUM eine Tabellenzeile einfrieren sollte
- vacuum_freeze_table_age: Alter, ab dem VACUUM die gesamte Tabelle prüfen sollte, um Tupel einzufrieren
- vacuum_multixact_freeze_min_age: Mindestens erforderliches Alter, ab dem VACUUM eine MultiXactId in einer Tabellenzeile einfrieren sollte
- vacuum_multixact_freeze_table_age: Multixact-Alter, ab dem VACUUM die gesamte Tabelle prüfen sollte, um Tupel einzufrieren
- wal_receiver_status_interval: Legt das maximale Intervall zwischen WAL-Empfängerstatusberichten auf „primär“ fest
- wal_writer_delay: Zeit zwischen im WAL-Schreiber durchgeführten WAL-Leerungen
- wal_writer_flush_after: Anzahl der vom WAL-Schreiber geschriebenen WAL, bei der eine Leerung ausgelöst wird
- work_mem: Legt den Arbeitsspeicher fest, der von internen Sortiervorgängen und Hashtabellen vor dem Schreiben in temporäre Datenträgerdateien verwendet werden soll
- xmlbinary: Legt fest, wie Binärwerte in XML codiert werden sollen
- xmloption: Legt fest, ob XML-Daten bei impliziten Analyse- und Serialisierungsvorgängen als Dokumente oder Inhaltsfragmente betrachtet werden sollen
Nächste Schritte
- Eine weitere Form der Konfiguration sind neben den Serverparametern die Konfigurationsoptionen für Ressourcen in einem Cluster.
- Die zugrunde liegende PostgreSQL-Datenbank verfügt auch über Konfigurationsparameter.