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

Re: Re

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 (view raw or flat)
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.

In response to

  • Re: Re at 2005-06-03 14:41:53 from Sébastien Dinot

Responses

  • Re: Re at 2005-06-03 15:56:07 from Sébastien Dinot
  • Re: Re at 2005-06-07 15:49:50 from Sébastien Dinot

pgsql-fr-generale by date

Next:From: Sébastien DinotDate: 2005-06-03 15:56:07
Subject: Re: Re
Previous:From: Sébastien DinotDate: 2005-06-03 15:00:24
Subject: Re: Be

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group