User Tools

Site Tools


wiki:postgres:pg_tune_kurs_pagelayout

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

wiki:postgres:pg_tune_kurs_pagelayout [2017/09/28 12:21] (current)
Line 1: Line 1:
 +====== Internes Layout einer Page ======
 +**Block = Page = Buffer = 8k**\\
 +
 +Nicht nur die Tabelle, sondern auch der **Index** besteht aus 8k-Blöcken. Innerhalb der 8k-Pages befindet sich ein "Mini B-Tree"​. Der Index zeigt auf einen limp (12 bit offset innerhalb der Page) Und das offset(Limp) zeigt auf den Datensatz. Dies hat den Vorteil, daß der Datensatz innerhalb der Page verschiebbar ist, ohne daß der Index angegriffen werden müsste.\\
 +\\
 +
 +**VACUUM FULL sollte man vergessen, da es effektive "​down-time"​ bedeutet. Viel besser ist es die (andauernde) Performance über eine gute "​Vacuum und Storage Policy"​ zu erhalten.**
 +
 +===== Visibility Map (VM) =====
 +
 +[[http://​www.postgresql.org/​docs/​9.0/​static/​storage-fsm.html|PostgreSQL9 Dokumentation:​ FSM]] \\
 +In der VM befindet sich ein **Hint bit** (Hinweis bit). VACUUM geht dann die VM durch, schaut wo es ein UPDATE oder DELETE gegeben hat und besucht diese Plätze dann nach der Reihe. Bei PostgreSQL9 muß also nicht mehr die gesamte "​Tabelle"​ durchforstet werden.
 +
 +===== Free Space Map (FSM) =====
 +
 +Jeder Heap und jede Index-Relation (außer hash-Indices) hat eine fsm um den freien Platz in einer Relation zu verfolgen. Siehe backend/​storage/​freespace/​README für Details.
 +  Mit contrib/​pg_freespacemap kann die in FSM gespeicherte Information angezeigt werden.
 +
 +====="​Tabelle"​=====
 +
 +===== FILLFACTOR =====
 +
 +  test# CREATE TABLE c_test(id int4);
 +  test# INSERT INTO c_test SELECT * FROM generate_series(1,​10000);​
 +  test# SELECT pg_size_pretty(pg_relation_size('​c_test'​));​
 +  pg_size_pretty
 +  ----------------
 +  360 kB
 +  ​
 +  test# CREATE TABLE t_test(id int4) WITH (fillfactor=20);​
 +  test# INSERT INTO t_test SELECT * FROM generate_series(1,​10000);​
 +  test# SELECT pg_size_pretty(pg_relation_size('​t_test'​));​
 +  pg_size_pretty
 +  ----------------
 +  1824 kB
 +  ​
 +Die Tabelle ist dann 5x so groß, da: 80% freier Platz, dann 20% Daten, 80% frei, 20% Daten usw.\\
 +Dies ermöglicht **HOT UPDATES**, d.h. die Tabelle wird durch updates nicht größer (bleibt dann z.B. 1824k).
 +  ​
 +  test# UPDATE t_test SET id = 100;
 +  test# SELECT pg_size_pretty(pg_relation_size('​t_test'​));​
 +  pg_size_pretty
 +  ----------------
 +  1824 kB
 +  ​
 +  test# UPDATE c_test SET id = 100;
 +  test# SELECT pg_size_pretty(pg_relation_size('​c_test'​));​
 +  pg_size_pretty
 +  ----------------
 +  712 kB
 +  ​
 +D.h. diese Tabelle wird bei einem UPDATE auf alle Zeilen doppelt so groß.
 +
 +==== Microvacuum ====
 +
 +**Hot Updates, CHAINING:** Der UPDATE Prozess macht von sich aus schon eine Bereinigung,​ wenn er daraufkommt daß die Kette (chaining) der Versionen (v1,v2,v3, ...) zu lange ist. Diese funktioniert nur wenn sich die Kette phyisch innerhalb einer Page befindet. Durch den **fillfactor** bleibt die Verkettung aufrecht. (hot update)
 +  test# ALTER TABLE t_test SET (fillfactor=70);​
 +  test# SELECT relname, reloptions FROM pg_class WHERE relname='​t_test';​
  
wiki/postgres/pg_tune_kurs_pagelayout.txt · Last modified: 2017/09/28 12:21 (external edit)