loeschen im insert-trigger

wenn ich in einem AFTER INSERT trigger die eingefuegte Zeile gleich wieder lösche - taucht die im WAL auf? Werden evtl. indizes geschrieben? Wie beansprucht das die DB?

Meine Lieblingsfrage an Dich: warum probierst Du es nicht mal selber aus?

Andreas

eigentlich wollte ich die sache allgemein zur diskussion stellen … hmm nagut … wenn niemand diskutieren will …

Wäre ja zu einfach. Andere tun das sicherlich für ihn …

Ihr beiden könnt das einfach besser als ich :wink:

Das mag sein, aber solange Du nicht mal selber versuchst zu lernen wird das nie was …

Andreas

und ich unterhalte mich mit euch so gerne ueber postgres … manchmal seid ihr nämlich ganz schön schlau

inzwischen habe ich die eigentlichen antworten die ich suchte …

Schön.

Und wenn du jetzt noch das Ergebnis hier postest, hat vielleicht ein anderer Suchender später auch etwas davon. Dafür ist ein Forum schließlich da.

das ergebnis ist eine entscheidung …

und zwar zu akzeptieren, dass bei einem RETURN NEW in einem BEFORE INSERT trigger das autovacuum arbeit bekommt, auch wenn ich den satz im AFTER wieder loesche … das ist aber der einzige weg, die generierte ID bei der INSERT-operation in einem zug zu erhalten …

ich bin nämlich kein freund davon stored procedures vom client aus direkt aufzurufen

man könnte auch nextval() nehmen …

Andreas

das wäre doch ein 2. aufruf ?! -> latenz

Rahmenbedingung ist, dass ich ein klassisches INSERT absetzen will … und RETURNING flexibel nutzen moechte …

Es geht um so vererbungskram - fast wie bei table-partitioning - da wuerde in der Mastertable ja bei BEFORE INSERT ein RETURN NULL stehen -> zonk …

insgesamt ist das anfallende autovacuum in einer effektiv immer fast leeren tabelle am billigsten

was meinst du

Wenn ich Dich richtig verstanden habe, willst Du ein Insert, was aber quasi wieder zurückgerollt wird (ohne die TX zu beenden), um lediglich die nächste ID einer Sequence zu ermitteln. Falls dem so ist, so schätze ich, ist ein nextval() um Größenordnungen einfacher und billiger als das, was Du da machst.

Andreas

nein … ich moechte tatsaechlich die row inserten - nur nicht in die table die im insert steht (thema partitionen) …

und returning will ich am leben erhalten … daher fallen rules ebenfalls weg

Das sind dann aber zwei Züge …

hmm - da fällt mir ein - wenn auf der table kein einziger index ist (braucht ja nicht - glaube ich) - solltes doch HOT’n …

HOT greift nur, wenn Platz da ist.

meine ich ja - solange autovacuum nicht aufgeraeumt hat duerfte da ja nicht viel wachsen … weil immer platz hergestellt wird -> DELETE

also selbst wenn AutoV sehr dezent eingestellt ist sollte das eine recht sparsame loesung sein