# Pg\_cron - gibt es eine funktionierende Beschreibung?
**URL:** https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687
**Category:** Allgemeines
**Created:** [4. Februar 2023 um 21:34 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687 "2023-02-04T21:34:41Z")
**Posts on this page:** 18
**Page:** 1
### Author:  [@Robbi](https://www.pg-forum.de/u/Robbi)
#### Post date: [4. Februar 2023 um 21:34 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/1 "2023-02-04T21:34:42Z")
Moin,
irgendwie komme ich mir langsam schon ein wenig doof vor.(ja ist etwas provokativ geschrieben).
Vielleicht sehe ich echt den Wald vor lauter Bäumen nicht.
Ich versuche folgendes einzutragen:
```auto
SELECT cron.schedule('15 1 3 * *', 'VACUUM(FULL, ANALYZE, VERBOSE)', 'photosupreme');
```
So lange ich hinten keine Datenbank eingebe ist alles gut. Versuche ich da eine Datenbank mitzugeben kommt nur:
```auto
FEHLER: invalid schedule: VACUUM(FULL, ANALYZE, VERBOSE)
```
Nach den Beschreibungen die ich gefunden habe, musste es aber so weit richtig sein.
Die einzige Möglichkeit die ich gefunden habe ist die Daten manuell in die cron.job Tabelle einzutragen. Das ist mir aber zu umständlich und dann bleibe ich lieber bei dem Linux cron.
Wo liegt mein Fehler?
---
### Author:  [@Robbi](https://www.pg-forum.de/u/Robbi)
#### Post date: [4. Februar 2023 um 23:47 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/2 "2023-02-04T23:47:06Z")
Ich kann zwar manuell alles in die cron.job Tabelle einfügen. Ausgeführt wird aber nichts.
---
### Author:  [@castorp](https://www.pg-forum.de/u/castorp)
#### Post date: [5. Februar 2023 um 08:41 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/3 "2023-02-05T08:41:05Z")
Das ist jetzt keine Antwort auf das Problem mit pg\_cron.
Aber diese und Deine andere Frage lassen vermuten, dass Du ein Problem mit autovacuum hast.
Der übliche Weg, Probleme mit autovacuum zu lösen ist, dieses aggressiver zu konfigurieren. Also so, dass es früher ausgelöst wird und dann auch mehr Arbeit verrichten darf. Regelmässig ein VACUUM manuell auszuführen ist eher eine Krücke als eine vernünftige Lösung.
Das erreicht man hauptsächlich dadurch, dass `autovacuum_vacuum_threshold` und `autovacuum_vacuum_scale_factor` verkleinert werden, so dass Autovacuum früher anspringt. Dazu sollte man `autovacuum_vacuum_cost_limit` erhöhen, damit bei jedem Lauf mehr Arbeit verrichtet werden kann. Wenn Dein Server viele CPUs hat, kannst Du auch noch `autovacuum_max_workers` erhöhen (dann muss aber cost\_limit noch stärker erhöht werden).
Hier sind zwei kurze Blog-Posts zu dem Thema:
- [https://www.2ndquadrant.com/en/blog/autovacuum-tuning-basics/](https://www.2ndquadrant.com/en/blog/autovacuum-tuning-basics/)
- [Postgres Autovacuum is Not the Enemy](https://www.citusdata.com/blog/2016/11/04/autovacuum-not-the-enemy)
---
### Author:  [@Robbi](https://www.pg-forum.de/u/Robbi)
#### Post date: [5. Februar 2023 um 10:13 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/4 "2023-02-05T10:13:39Z")
> [@castorp](#):
>
> Aber diese und Deine andere Frage lassen vermuten, dass Du ein Problem mit autovacuum hast.
Hmm das weiß ich nicht. Bin mir dessen nicht wirklich bewusst.
Ich hatte ein Problem mit meiner Anwendung für die Verwaltung meiner Bilder. Damit Tagsüber mir autovacuum mir die Performance nicht runterzieht, habe ich es explizit deaktiviert.
So wollte ich die vacuum komplett auslagern, in Zeiten wo sonst nichts gemacht wird. Dazu habe ich mir normale Linux cron Jobs eingerichtet. Dabei habe ich mich gewundert, dass Statistiken nicht aktualisiert werden (habe dabei leider nur auf vacuum geschaut und wenn ich vacuum full laufen lasse, werden eben diese Statistiken nicht aktualisiert)
Dann bin ich beim Suchen auf pg\_cron gestoßen und dachte mir - vielleicht wird damit “schöner/ besser/ bunter”. Sieht nicht so aus, Wenn ich nichts übersehen habe, sind es mir zu viele Stellen wo das nicht das machen kann was ich brauche oder wie ich es mir vorstelle.
Es mag aber an dem von mir eingesetzten Debian und PG14 liegen.
Es ist nicht möglich mit select cron.schedule… Datenbank für die etwas passieren soll einzutragen. Vielleicht geht das erst mit PG15 und pg\_cron15
Man muss also die Sachen in die Tabelle cron.job eintragen. Das Problem hier - Die Sachen arbeiten mit UTZ und nicht mit localtime. So lange wir hier “hin und her” springen mit der Zeit, musste ich auch die Jobs selbst korrigieren damit es mit anderen Sachen nicht kollidieren.
Zumindest so lange ich keine Lösung finde wie ich in der cron.job Tabelle so etwas wie ‘15 1 3 \* \*’ at localtime eintragen kann, werde ich bei Linux cron bleiben.
---
### Author:  [@akretschmer](https://www.pg-forum.de/u/akretschmer)
#### Post date: [5. Februar 2023 um 10:22 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/5 "2023-02-05T10:22:45Z")
IIRC kannst Du bei VACUUM nur eine Tabelle angeben, nicht aber eine (andere) Datenbank.
```auto
postgres=# vacuum ;
VACUUM
postgres=# vacuum template1;
ERROR: relation "template1" does not exist
```
Und das cron\_schedule hat 2 Syntaxformate, aus der Doku:
[code]
```auto
cron.schedule (job_name,
schedule,
command
);
cron.schedule (schedule,
command
);
```
Aber vielleicht liege ich da auch flasch, ich habe das noch nie genutzt.
---
### Author:  [@castorp](https://www.pg-forum.de/u/castorp)
#### Post date: [5. Februar 2023 um 10:30 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/6 "2023-02-05T10:30:51Z")
> [@Robbi](#):
>
> Damit Tagsüber mir autovacuum mir die Performance nicht runterzieht, habe ich es explizit deaktiviert.
Ganz schlechte Idee.
Wie gesagt: die bessere Option ist, autovacuum so zu konfigurieren, dass es viel “früher” und öfter zum Zuge kommt und damit letztendlich weniger zu tun hat. Die Angst das autovacuum die Datenbank “runterzieht” ist unbegründet.
In den meisten Fällen ist das aber sowieso nur notwendig wenn man eine Anwendung hat, die ohne Pause tausende von Transaktionen in der Minute durchführt.
Hast Du denn wirklich ein Problem mit dem autovacuum Daemon? Wenn ja, was genau war/ist das Problem?
---
### Author:  [@Robbi](https://www.pg-forum.de/u/Robbi)
#### Post date: [5. Februar 2023 um 12:53 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/7 "2023-02-05T12:53:52Z")
> [@akretschmer](#):
>
> Und das cron\_schedule hat 2 Syntaxformate, aus der Doku:
Vielleicht war es gestern doch zu spät: Aus dem GitHub:
```auto
[tippe oder füge den Code hier ein](https://github.com/citusdata/pg_cron)
SELECT cron.schedule_in_database('weekly-vacuum', '0 4 * * 0', 'VACUUM', 'some_other_database');
```
Gestern ging das nicht. Vermutlich habe ich mich vertippt oder in anderer DB es versucht oder…
Es bleibt das Problem mit der Timezone
> [@castorp](#):
>
> Hast Du denn wirklich ein Problem mit dem autovacuum Daemon?
Nein, ich habe es deaktiviert auf Empfehlung des Entwicklers der Anwendung deaktiviert.
Ich denke und schaue mir Dein Vorschlag auf jedem Fall an und werde probieren ob es in der Tat irgendwelche Nachteile für mich bringt.
Ein Szenario wo es sicherlich ungünstig wäre habe ich schon aus meinem allerersten Post hier im Forum… Die Anwendung hat zumindest im Moment noch ein BUG und zwar selten aber es kommt X mal im Jahr vor, dass sie der Meinung ist - alle Daten von der Platte neu einlesen zu müssen. Und das wären nicht nur Tausende sondern Millionen von Transaktionen die eben ohne Pause laufen.
(Hier wäre die Frage - kann man ggf. autovacuum deaktivieren ohne den Server Stoppen/ Starten zu müssen? Also für den Fall, dass so eine Situation kommt, dass ich eben autovacuum daemon deaktivieren kann und später wieder aktivieren)
---
### Author:  [@castorp](https://www.pg-forum.de/u/castorp)
#### Post date: [5. Februar 2023 um 13:28 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/8 "2023-02-05T13:28:19Z")
> [@Robbi](#):
>
> Nein, ich habe es deaktiviert auf Empfehlung des Entwicklers der Anwendung deaktiviert.
Das halte ich für eine sehr zweifelhafte Empfehlung. Das war vielleicht vor 20 Jahren mit Postgres notwendig, aber heute sicherlich nicht mehr.
> [@Robbi](#):
>
> Und das wären nicht nur Tausende sondern Millionen von Transaktionen die eben ohne Pause laufen.
Nach einem Bulk-Load großer Datenmengen macht es durchaus Sinn ein `vacuum analyze` laufen zu lassen (wenn sehr viel via DELETE gelöscht wurde, dann vielleicht, möglicherweise, unter Umständen sogar `vacuumn full analyze`)
---
### Author:  [@Robbi](https://www.pg-forum.de/u/Robbi)
#### Post date: [5. Februar 2023 um 17:35 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/9 "2023-02-05T17:35:49Z")
Ich aktiviere autovacuum und schaue mir das die nächste Zeit an ob es mich in irgendeiner Art stört/ hindert (Performance-Seiting natürlich).
Ich habe nach zugegeben schnellen durchlauf der beiden Blogs und etwas Google folgendes eingestellt:
```auto
< vacuum_cost_limit = 2000
< autovacuum = on
< autovacuum_max_workers = 4
< autovacuum_vacuum_threshold = 500
< autovacuum_vacuum_scale_factor = 0.4
< autovacuum_vacuum_cost_limit = -1
```
---
### Author:  [@castorp](https://www.pg-forum.de/u/castorp)
#### Post date: [5. Februar 2023 um 18:01 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/10 "2023-02-05T18:01:24Z")
Der Scale Factor ist zu hoch für meinen Geschmack. Das bedeutet, dass autovacuum erst einsetzt wenn 40% der Datensätze geändert wurden. `0.1` oder `0.05` ist meiner Meinung nach ein besserer Wert.
---
### Author:  [@Robbi](https://www.pg-forum.de/u/Robbi)
#### Post date: [5. Februar 2023 um 18:43 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/11 "2023-02-05T18:43:20Z")
> [@castorp](#):
>
> Der Scale Factor ist zu hoch für meinen Geschmack
Ja vielleicht/ vermutlich hast Du recht. Ich habe den Wert erst mal auf Standard also 0.2 verändert.
Warum ich nicht sofort auf 0.1 oder 0.05 gegangen bin? - Unsicherheit was das ganze mir auf Dauer ausrichtet. Nach dem ich autovacuum wieder aktiviert habe, hat es sofort losgelegt und bei den 2 großen Datenbanken etwas über 80GB ist es eben noch am machen. Warum ist mir nicht so ganz klar. (habe vermutlich falsche Vorstellung von dem wie es funktioniert. Bin nun mal kein DBA Profi)
---
### Author:  [@akretschmer](https://www.pg-forum.de/u/akretschmer)
#### Post date: [5. Februar 2023 um 18:52 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/12 "2023-02-05T18:52:37Z")
> [@Robbi](#):
>
> Warum ich nicht sofort auf 0.1 oder 0.05 gegangen bin? - Unsicherheit was das ganze mir auf Dauer ausrichtet.
Es wird eher anspringen, aber weniger Load/Last verursachen. Maintenance\_work\_mem könnte man auch erhöhen, falls möglich.
---
### Author:  [@akretschmer](https://www.pg-forum.de/u/akretschmer)
#### Post date: [5. Februar 2023 um 18:54 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/13 "2023-02-05T18:54:19Z")
Ma muß bei all dem immer im Kopf behalten: es ist IMMER der Versuch, eine Balance zu finden. Es gibt keine ‘Goldene Regel’, die immer gilt.
---
### Author:  [@Robbi](https://www.pg-forum.de/u/Robbi)
#### Post date: [6. Februar 2023 um 16:49 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/14 "2023-02-06T16:49:16Z")
> [@akretschmer](#):
>
> Maintenance\_work\_mem könnte man auch erhöhen, falls möglich.
Das habe ich mir auch gedacht und auf 2GB gesetzt.
(Auch wenn ich doch bei Linux PG vermutlich bleiben werde, habe ich PG14 auf gleich ausgetasteter Windows 2019 VM am laufen. Hier verweigerte PG die Änderung mit der Meldung - ist ein Fehler in der Konfig. Also maintaince\_work\_mem mit 1GB geht mit 2GB will er nicht akzeptieren)
> [@akretschmer](#):
>
> es ist IMMER der Versuch, eine Balance zu finden
Das ist schon klar. Deswegen bin ich Euch sehr Dankbar für die viele Vorschläge und Rückmeldungen.
Ich habe gestern so ein BLOG Eintrag gelesen [Ajay’s PostgreSQL Blog](https://postgresqlblog.substack.com/p/postgresql-performance-and-tuning)
Und hier irritiert mich ein wenig diese Passage
> The choice between autovacuum and manual vacuum depends on the specific requirements of the database and the resources available. Autovacuum is generally considered to be the best option for most scenarios, as it can be configured to run at times when the load on the database is low, and it can be fine-tuned to minimize the impact on performance. However, manual vacuum can be useful for specific scenarios, such as reclaiming space from large tables or for debugging and troubleshooting purposes.
Was mich irritiert - wie stellt man ggf. ein, dass autovacuum dann anspringt wenn gerade wenig/ nichts zu tun ist?
---
### Author:  [@akretschmer](https://www.pg-forum.de/u/akretschmer)
#### Post date: [6. Februar 2023 um 16:59 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/15 "2023-02-06T16:59:52Z")
Gute Frage. Frag doch mal den Autor des Blogs…
---
### Author:  [@WolfgangW](https://www.pg-forum.de/u/WolfgangW)
#### Post date: [24. März 2023 um 17:06 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/16 "2023-03-24T17:06:53Z")
Die Verwendung von FULL im VACUUM ist auch grenzwertig. VACUUM FULL kopiert die komplette Tabelle, leert gerade mal die “toten” Elemente und blockiert während der Zeit die ganze Tabelle.
---
### Author:  [@Robbi](https://www.pg-forum.de/u/Robbi)
#### Post date: [2. April 2023 um 19:50 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/17 "2023-04-02T19:50:27Z")
An sich hätte es mich nicht weiter gestört, weil ich es immer für die Zeiten eingestellt hätte, wo ich eh nichts mehr mache.
Für den Moment bin ich aber auf den Vorschlag eingegangen und schaue wie gut/ schlecht es mit dem autovacuum funktionieren wird.
---
### Author:  [@system](https://www.pg-forum.de/u/system)
#### Post date: [1. Juni 2023 um 19:50 UTC](https://www.pg-forum.de/t/pg-cron-gibt-es-eine-funktionierende-beschreibung/12687/18 "2023-06-01T19:50:55Z")
Dieses Thema wurde automatisch 60 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Antworten mehr erlaubt.