From: | Stéphane Bunel <stephane(at)stratum-ip(dot)net> |
---|---|
To: | Sébastien Dinot <sebastien(dot)dinot(at)free(dot)fr> |
Cc: | pgsql-fr-generale(at)postgresql(dot)org |
Subject: | Re: Re |
Date: | 2005-06-03 15:27:10 |
Message-ID: | 42A076CE.2050102@stratum-ip.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-fr-generale |
Sébastien Dinot wrote:
(...)
>
> A part cela, autre élément important que j'ai oublié de préciser,
> entre deux blocs de 10 000 données, le script Perl lance :
>
> - un VACUUM des tables modifiées ;
>
> - un VACUUM et un ANALYZE lorsque le nombre d'enregistrements a
> augmenté de plus de 50 % depuis le dernier ANALYZE.
[(reprise)]
> Or, ces tables ont exactement la même structure, les mêmes clés
> primaires et étrangères et les mêmes index. Elles sont toutes les deux
> clusterisées sur le même index.
Ne présumant de rien quant à votre problème, j'espère ne pas être hors
sujet en rappelant qu'avant la version 8 de PG, un VACUUM (*) n'implique
pas un CLUSTER. Ce dernier doit donc être explicite dans votre cas afin
de réordonner les données.
En revanche CLUSTER est assez gourmand en ressource temps et espace
puisque créant une copie temporaire de la table et du (des) indexe(s).
Puis, il est fort utile pour l'optimiseur de lancer un ANALYSE après
l'ordre CLUSTER afin qu'il évite des choix trop malheureux.
Enfin, l'augmentation des caches de PG est à prendre sérieusement en
considération des lors que les tables sont "grande".
Stéphane BUNEL.
From | Date | Subject | |
---|---|---|---|
Next Message | Sébastien Dinot | 2005-06-03 15:56:07 | Re: Re |
Previous Message | Sébastien Dinot | 2005-06-03 15:00:24 | Re: Be |