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

Re: Re

From: Sébastien Dinot <sebastien(dot)dinot(at)free(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Re
Date: 2005-06-03 15:56:07
Message-ID: 20050603155607.GA3632@newtech.fr (view raw or flat)
Thread:
Lists: pgsql-fr-generale
Stéphane Bunel a écrit :
| 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.

Je ne suis pas certain de bien vous comprendre. D'après ce que j'ai lu
dans la doc. PostgreSQL, il faut invoquer explicitement la commande
CLUSTER une première fois. Cet préférence de tri est mémorisée par PG
qui par la suite la satisfait à chaque VACUUM. Ainsi, dans la doc de
PG 7.4.7 (page sql-cluster.html), il est écrit :

« Because CLUSTER remembers the clustering information, one can
  cluster the tables one wants clustered manually the first time, and
  setup a timed event similar to VACUUM so that the tables are
  periodically reclustered.

  Because the planner records statistics about the ordering of tables,
  it is advisable to run ANALYZE on the newly clustered table.
  Otherwise, the planner may make poor choices of query plans. »

En ce qui me concerne, après avoir créé les tables et les index,
j'invoque la commande CLUSTER. Les tables sont alors vides mais je
compte justement sur la mémorisation de cette préférence de tri pour
que le VACUUM arrange de manière optimale les données par la suite.

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

C'est donc pour cela que le VACUUM prend du temps même lorsque la
table n'a pas été modifiée...

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

J'ai vu cela aussi dans la doc et les ANALYZE réguliers que je lance
sont censés y veiller. (c:

| Enfin, l'augmentation des caches de PG est à prendre sérieusement en
| considération des lors que les tables sont "grande".

Sans être un expert en la matière, j'ai essayé d'optimiser les caches
(en réduisant d'ailleurs le nombre de personnes pouvant se connecter
simultanément à la base pour pouvoir augmenter la taille des caches
alloués à chaque utilisateur).

Extrait du fichier postgresql.conf :

----------------------------------------------------------------------

#max_connections = 100
max_connections = 25

#shared_buffers = 1000   # min 16, at least max_connections*2, 8KB each
shared_buffers = 16384

#sort_mem = 1024         # min 64, size in KB
sort_mem = 65536

#vacuum_mem = 8192       # min 1024, size in KB
vacuum_mem = 16384

#wal_buffers = 8         # min 4, 8KB each
wal_buffers = 128

----------------------------------------------------------------------

Sébastien


-- 
Sébastien Dinot, sebastien(dot)dinot(at)free(dot)fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

In response to

  • Re: Re at 2005-06-03 15:27:10 from Stéphane Bunel

Responses

  • Re: Re at 2005-06-03 16:23:05 from Daniel Verite
  • Re: Re at 2005-06-04 10:03:48 from Stephane Bunel

pgsql-fr-generale by date

Next:From: Daniel VeriteDate: 2005-06-03 16:23:05
Subject: Re: Re
Previous:From: Stéphane BunelDate: 2005-06-03 15:27:10
Subject: Re: Re

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