Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: Haeufige Updates in Tabelle mit vielen/breiten Spalten



Alvar Freude writes:

> Wenn Postgres ein Update auf eine Spalte macht, wird aufgrund der
> Transaktionen immer eine komplette Kopie der Spalte angelegt. (wenn ich
> mich nun nicht irre)

s/Spalte/Zeile/, da MVCC ja Zeilenweise agiert.

> Angenommen, ich habe eine Tabelle mit relativ vielen Spalten, einigen
> Texten usw. und eine Spalte davon wird relativ häufig aktualisiert, zum
> Beispiel ein Counter.

Wenn die Text-Felder groß genug sind (> 2kB IIRC), wird darin nur ein
Zeiger auf die passende Toast-Tabelle abgelegt. MVCC-Kopien werden in
dem Fall dann nur von den verbleibenden Zeigern gemacht, und nicht von
Inhalt der Toast-Tabellen.

> Hat jemand Erfahrungswerte, ob bzw. ab wann es sinnvoll ist, diese Spalte
> (oder mehrere häufig zu aktualisierende Spalten) in eine andere Tabelle
> zu verfrachten, damit beim Update nicht immer von allen Spalten (und
> Texten) Kopien angelegt werden müssen und große Lücken entstehen? Oder
> ist das eher Quatsch?

Also ich hatte durchaus schon Fälle, in denen man gerade so unter der
Toast-Grenze lag, und dadurch in rasantem Tempo tote Seiten produziert
wurden. Hier lohnte es sich dann, "manuell zu toasten".

Ich könnte mir auch vorstellen, daß man in macnhen Fällen auch via
"alter table set storage" feineinstellen kann, welche der Felder im
Zweifelsfall getoastet werden.

> Beim Auslesen muss ja auch ein Join gemacht werden und außerdem ist
> dann zwei mal der Overhead für die Spalten-Basisdaten nötig.

Sollte einklich unproblematisch sein, da genau das impliziert wird,
wenn Postgres sich für's toasten entscheidet.

Gruß
Andreas
-- 

Attachment: pgpXhbJRn66hu.pgp
Description: PGP signature



Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group