Re: [postgresql-it] Consiglio su separazione campi di una tabella
- From: Daniele Varrazzo <piro@xxxxxxxxxxx>
- To: postgresql-it <postgresql-it@xxxxxxxxxxxxx>
- Date: Wed, 02 Apr 2008 12:59:12 +0200
Giorgio Ponza ha scritto:
Ing. Claudio Rossi wrote:
Se ho capito in modo corretto, il tuo database non e' normalizzato.
Potresti scrivermi lo schema della tabella (o almeno un esempio
simile) e dire quali campi sono quelli che richiedono ulteriori insert
e quali rimangono uguali invece?
Molto volentieri, ecco lo schema della tabella a cui ho scritto sulla
destra --> FISSO se il campo viene scritto solo all'inserimento del
record e mai modificato, oppure --> UPDATE se invece viene aggiornato
almeno una volta
Ciao,
secondo me la tua situazione merita un tentativo: potresti trovare benefici
nel vacuum ma ovviamente il join che dovrai fare avrà un'influenza. Quanto
saranno grandi i benefici e l'influenza però è da provare. Un join su una
coppia di tabelle 1-1 non mi sembra mostruoso, e lì comunque hai molti margini
di ottimizzazione (indici parziali ecc.) e puoi controllare bene cosa combina
il query planner. Sono abbastanza sicuro che non avresti un grosso danno dal
join, ma non ho esperienza sull'influenza che avrebbe sul vacuum).
Sono in tutto 16 campi fissi e 10 aggiornabili. Quello che pensavo io
era di spostare i 10 campi aggiornabili in una tabella separata (visto
che contengono molti meno dati dei 16 fissi), in relazione 1-1.
Il ragionamento che facevo io era sul vacuum full, in quanto con questa
soluzione la tabella con tante tuple segnate 'vacuumable' sarebbe piu'
piccola (dal punto di vista dello spazio occupato) e teoricamente il
tempo impiegato migliore.
Hai verificato, con un "vacuum full verbose", se è questa la tabella che fa
perdere più tempo? (o magari hai altre euristiche... semplicemente questa è
l'unica tabella di dimensione significativa del db...)
Da questo ragionamento poi, volendo essere piu' teorici, si potrebbe
fare un discorso su come comportarsi in questi casi, cioe' conviene
separare sempre le tabelle in questo modo?
In effetti il problema è interessante.
Vedo anche che la tua tabella ha molti campi che colpiscono l'aera TOAST (i
VARCHAR e i BYTEA). Mi chiedo se questi campi abbiano un'influenza negativa
durante il vacuum full (anche qui forse il verbose ti dice qualcosa). Mi
chiedo, se nella tabella ad aggiornamento frequente non ci fosse nessuno di
tali campi, se comporterebbe un ulteriore incremento di prestazioni nel
vacuum. Vedo comunque che un paio di tali campi restano (pos_trip e
pos_direction, se non sbaglio): è davvero necessario che siano campi testuali
senza una lunghezza massima definita? Magari sono un insieme finito di valori
che puoi normalizzare scrivendoli in altre tabelle e accedendoli via fkey. O
di cui puoi stabilire una lunghezza massima tale che il record rientri in una
pagina. (Sto sempre ragionando senza sapere il dettaglio di quale sia
l'interazione tra vacuum e toast).
Qualcuno (un Rotellaro a caso...) sa cosa succede ad un campo TOASTabile se la
dimensione del dato rientra nella pagina? Va lo stesso nel TOAST o viene
memorizzato nella pagina?
Nota anche che in Postgres 8.3 c'è una feature (HOT tuples) che dovrebbe
servire esattamente ad ottimizzare il tuo caso: quando ci sono aggiornamenti
di record che non influenzano colonne indicizzate. Se ti è possibile un
aggiornamento, te lo consiglio. Anche qui a occhio e cazzotto avere l'intero
record nella pagina potrebbe essere un beneficio.
Ciao!
--
Daniele Varrazzo - Develer S.r.l.
http://www.develer.com
Other related posts:
