Nun, die Funktion wird bei der Erstellung geplant. Zu diesem Zeitpunkt weiß der Planner allerdings nicht, welche aktuellen Parameter im WHERE sind. Dies führt leider oft zu seq-scans bei der Abarbeitung.
Abhilfe wäre hier vielleicht mittels EXECUTE 'dynamisches SQL'.
Wenn Du so viele Insert/Updates hast, würde ich aber generell anders vorgehen: alles erst einmal via COPY in eine Import-Tabelle werfen und aus dieser mittels Insert und Update die Daten in die eigentliche Zieltabelle bringen. Das geht mit Sicherheit erheblich schneller.
Andreas
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
achso na das erklärt einigesNun, die Funktion wird bei der Erstellung geplant. Zu diesem Zeitpunkt weiß der Planner allerdings nicht, welche aktuellen Parameter im WHERE sind. Dies führt leider oft zu seq-scans bei der Abarbeitung.
Abhilfe wäre hier vielleicht mittels EXECUTE 'dynamisches SQL'.
Das hast du mir bereits in dem anderen Beitrag empfohlen und das habe ich auch zu Herzen genommen, habe mich aber bewusst erstmal dagegen entschieden. Optimierungenspotezial muss ich mir auch noch lassenWenn Du so viele Insert/Updates hast, würde ich aber generell anders vorgehen: alles erst einmal via COPY in eine Import-Tabelle werfen und aus dieser mittels Insert und Update die Daten in die eigentliche Zieltabelle bringen. Das geht mit Sicherheit erheblich schneller.Aktuell sieht alles sehr gut aus und ich sag mal vielen Dank für deine Bemühungen.
Da wirst du wohl mal ein EXPLAIN auf das Problem werfen müssen.
Oh, und zu deinen Einstellungen: du solltest mehr Transaktionslogs haben, so im Bereich ab 20 oder 30.
Dann sollte das Problem weggehen.
Beobachten kannst du das im Log, indem du "log_checkpoints" auf "on" setzt.
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Jo hab ich bereits gemacht und es wurde ein Tablescan gemacht wie akretschmer schon vermutet hatte.Da wirst du wohl mal ein EXPLAIN auf das Problem werfen müssen.
Das ist ja nur eine Erstbefüllung und keine Regelbefüllung. Dort werden die Mengen bei ca. 60k liegen. Aber es schadet ja nicht 20 zu setzten außerdem das im Fehlerfall mehr Transaktionen rückgängig gemacht werden, oder?Oh, und zu deinen Einstellungen: du solltest mehr Transaktionslogs haben, so im Bereich ab 20 oder 30.
Dann sollte das Problem weggehen.
Beobachten kannst du das im Log, indem du "log_checkpoints" auf "on" setzt.
Ich glaube ich werde nun doch den Weg gehen, da es mich doch reizt hier noch was an Geschwindigkeit raus zu kitzelnWenn Du so viele Insert/Updates hast, würde ich aber generell anders vorgehen: alles erst einmal via COPY in eine Import-Tabelle werfen und aus dieser mittels Insert und Update die Daten in die eigentliche Zieltabelle bringen. Das geht mit Sicherheit erheblich schneller.![]()
Xandrian: Kurz gesagt: Du hast ein falsches Konzept und willst nicht auf ads hören
Jetzt NEU: PostgreSQL - Datenbankpraxis für Anwender, Administratoren und Entwickler
PostgreSQL Service & Support
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen