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
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.

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

Browse pgsql-fr-generale by date

  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