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

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

Re: Problème de select suivant un update


  • From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
  • To: Valérie SCHNEIDER <valerie(dot)schneider(at)meteo(dot)fr>
  • Cc: pgsql-fr-generale <pgsql-fr-generale(at)postgresql(dot)org>, Pierre <pierre(dot)dupre(at)meteo(dot)fr>
  • Subject: Re: Problème de select suivant un update
  • Date: Thu, 05 Jun 2008 14:03:30 +0200
  • Message-id: <4847D612.10805@lelarge.info> <text/plain>

Guillaume Lelarge a écrit :
Valérie SCHNEIDER a écrit :
[...]
Question: je suis très surpris du temps de sélection
  du cas (3) qui est très grand par rapport aux autres
  select, et pour ne récupérer aucune ligne (car un
  update précédent les a déplacées).


Pour être franc, moi aussi. Je viens de faire sept tests (et j'en prépare un huitième qui s'exécutera pendant que je dormirais), tous ont à peu de choses près la même durée d'exécution alors que le paramétrage est bien différent. Je n'ai pas encore tout analysé car j'évite d'utiliser ma machine pendant le test, mais il semble que j'avais raison pour les écritures pendant le premier SELECT et l'absence d'écritures pendant le second. Cependant, ma conclusion me paraît maintenant suspecte. Je vais continuer à me pencher dessus car j'avoue que je ne comprends pas du tout ce qu'il se passe (et ça m'ennuie beaucoup :) ).


Je viens de faire un petit tableau sur les neuf tests que j'ai finalement fait (les nombres sont des secondes) :

	UPDATE	ANALYZE	CHECKPOINT	SELECT	SELECT
Test 1	992				292	0,02
Test 2	945	27,31	13,7		275,52	0,02
Test 3	942	33	22		724	2,14
Test 4	946	31	29		709	2,5
Test 5	924	47	21		644	0,3
Test 6	942	33	9,8		699	1,3
Test 7	953	33,8	9,99		683	1
Test 8	810	26	99		23	8
Test 9	869	32	9,7		375	45

Il est tout à fait étonnant que je multiplie par 3 le temps pour le premier SELECT entre les tests 2 et 3 (la seule différence entre les deux est la config où j'ai passé les checkpoint_segments de 3 à 30).

On remarque que le temps d'exécution de l'UPDATE ne varie presque pas, sauf sur les tests 8 et 9 (particularité de ces tests, un effective_cache_size passé de 128 Mo, valeur par défaut, à 1 Go)

Le test intéressant est le 8.

Différence de config entre test 7 et test 8 :
 * passage de shared_buffers de 50 Mo à 1 Go
 * passage de effective_cache_size de 128 Mo à 1 Go

Différence de config entre test 8 et test 9 :
 * passage de shared_buffers de 1 Go à 50 Mo
 * passage de effective_cache_size de 1 Go à 1,3 Go


Différence entre votre config et la mienne :
 * passage de shared_buffers de 32 Mo à 1 Go
 * passage de wal_buffers de 64 Ko à 1 Mo
 * passage de checkpoint_segments de 3 à 30
 * passage de checkpoint_timeout de 5min à 15 min
 * passage de effective_cache de 128 Mo à 1 Go

(j'ai supprimé les différences inintéressantes du côté des perfs)

Je voulais rejouer le test 8 mais je viens de m'apercevoir, en redémarrant, j'ai perdu la base :-/

Je dois la reconstruire, ça va prendre un peu de temps. À faire :
 * de nouveau le test 8
 * un test en modifiant la quantité de stats sur la table.


--
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com



Home | Main Index | Thread Index

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group