_rr hat geschrieben:Das ganze ist so aufgebaut, dass ich nachher in der ersten Funktion die Tabelle+Schema angeben kann und dann automatisch der Inhalt aus einer normalen Tabelle in die Nestedsettabelle übertragen wird, in der der Inhalt der Spalte num die oberste Ebene ist, der alte Tabellenname zweite Ebene und der Inhalt der alten Tabelle dort unterhalb eingefügt wird.
Ich hoffe es wird halbwegs verständlich.
Ich habe es nach und nach versucht den Überltäter zu finden. Es scheint am längsten zu brauchen, bei den Updates in der Nestedset-Funktion. Das zusammenbauen zum Aufrufen der Funktion geht schnell.
Ich habe die zu übergebenen Parameter an die Nestedset-Funktion auch in eine Tabelle geschrieben, um sie dann von dort aus wieder aufzurufen, gleiches Problem.
Er wird halt nach ein paar Datensätzen langsamer, wobei ich glaube das es daran liegen kann, dass Postgres sich die geänderten Daten erst merkt (WAL?) und erst am Ende schreibt. Und da fast jeder vorhandener Datensatz mit jeden neuem Datensatz geändert wird kommen ziemlich viele Änderungen zusammen. Dafür habe ich aber eben schon fast jeden Tuningtrick probiert den ich finden konnte um dieses Problem zu beheben.
So, ich hoffe es ist verständlich. Danke schon mal im Voraus.
Da durchzusteigen hab ich wenig Lust, aber, was mir so aufgefallen ist:
- warum so viele Indexe? Die zu aktualisieren ist teuer
- warum so viele BIGINT, wenn es doch nur ein paar tausend Zeilen sind?
- die verschachtelten EXECUTE - Anweisungen sorgen dafür, daß da jedesmal neu geplant wird, auch das kostet Zeit
Fakt ist, bei so einer Update-lastigen Aktion entstehen massig tote Tupel, und es ist viel WAL zu schreiben. Ads kann da vielleicht was zum Tuning schreiben, was ich mich frage: wären rekursive Abfragen (PG 8.4+) nicht sinnvoller?
Andreas