Tablespaces machen nur Sinn, wenn man mehrere Festplatten hat. Ansonsten erreicht man dadurch nichts.
Nun, Chancengleichheit? An sich will man ja die beste Lösung und nicht die langsamste. Also sollte man über einen Umbau nachdenken.
Tablespaces lohnen nur, wenn es unterschiedliche Platten / Controller sind. Dann können I/O-Operationen gleichzeitig ablaufen, z.B. das Insert in die eigentlichen Tabellen UND das schreiben des WAL-Logs.
Du hast 2 Tabellen, Master und Detail. In Master willst Du einen Record eintragen, in Detail dann die ID von Master und N Detaildatensätze. Normalerweise also ein Insert in Master und N Inserts in Detail.Kannst du das näher beschreiben, was du damit genau meinst?
Mit writeable CTE bekommst Du all das in ein einziges Statement. Du sparst massig Zeit durch weniger I/O, weniger Planner-Arbeit etc. Was das in der Realität bringt, habe ich mal untersucht, hier: my blog: writeable CTE - a short performance test
Das ist eine schlechte Idee ...
Das habe ich alles berücksichtigt und auch autocommit wollte ich ausschalten über explizite Transaktion. Ist allerdings eine PL/pqSQL Funktion, über die die Inserts in die DB kommen
Andreas
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Tablespaces machen nur Sinn, wenn man mehrere Festplatten hat. Ansonsten erreicht man dadurch nichts.
Nun, Chancengleichheit? An sich will man ja die beste Lösung und nicht die langsamste. Also sollte man über einen Umbau nachdenken.
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
Wenn ich es mal mit writeable CTE innerhalb der PL/pgSQL Funktion versuche, spricht dass doch für Chancengleichheit und Performancegewinn, oder?
Kann ich das mit der Version 8.4?
Was ist mit 8.5devel gemeint?Und wenn es Inserts in Tabellen sind, die via RI zusammenhängen, und da dann auch die erzeugten IDs mit currval() abzufragen sind oder solche Dinge, dann writeable CTE nutzen (8.5devel) *g*
mfg
Marcus
er meinte 8.5. devildas ist noch nix ..
nein - du solltest erstmal darueber nachdenken, die methode zu aendern wie du daten in die db schreibst .. der aufruf einer funktion scheint uns nicht besonders geeignet zu sein.
ich empfehle INSERT INTO anzuwenden und in der zieltabelle alles weitere dahin zu triggern wo es hin gehoert
und nachwievor .. INSERTS zusammenfassen - der client startet eine transaktion, INSERTed ein paar rows und committed die Transaktion .. Die INSERTs kannst du auch zusammenfassen .. siehe INSERT .. VALUES (), (), ()
Geändert von symbiont (23.11.2009 um 10:22 Uhr)
Nein.
Nein.Kann ich das mit der Version 8.4?
Das, was der Name suggeriert: die derzeitige Entwicklerversion der nächsten Version 8.5. Und writeable CTE sind noch nicht einmal in der Alpha-Version enthalten, sondern bedürfen extra noch eines speziellen Patches. Das ist also alles noch ein ganzes Stück weit entfernt, produktiv stable zu sein.Was ist mit 8.5devel gemeint?
mfg
Marcus
Andreas
--
https://www.xing.com/profile/Andreas_Kretschmer7ads Das hatte dir akretschmer gestern schon gesagt und siehe da sobald du das machst, funktioniert es ;-)
Links: Tobias Bauer - IT- und Funkdienstleistungen - Bilderrahmen-kaufen.de - Der Onlineshop für Bilderrahmen & Fotorahmen - Funkforum
Lesezeichen