Re: Problème de select suivant un update

[Guillaume Lelarge <guillaume(at)lelarge(dot)info>]

Bonsoir... enfin bonjour plutôt :)

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

> Remarque: dans ma description détaillée j'ai utilisé
>   entre les requêtes les commandes:
> 	select * from pg_statio_all_tables 
> 	where relname = 'test_update';
>   décrite dans l'article sur PostgreSQL de Juin 2008
>   dans Gnu Linux Magazine France, afin des voir l'utilisation
>   des caches postgresql et les blocks lus sur le disque dur.

De mon côté, j'ai conservé les stats du bgwriter, j'espère en tirer 
quelque chose demain.

Bonne nuit.


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