Re: Problème d'update : résolu !!!

[Valérie SCHNEIDER <valerie(dot)schneider(at)meteo(dot)fr>]

Encore rebonjour,

Je pense qu'on a trouvé notre problème : l'update est :
update diffusion_2008_05_13 set state = 3001 where state = 2101 and
next_try_channel like 'FTP' and next_try_key like 'uatos_a+host_atos_a
+datos_a+21';

Or dans les conditions on compare un champ à une chaine ... qui contient
des "_" : et vlan... (on a mal lu : le "filter" est correct, mais le
index condition limite au début de chaine jusqu'au premier "_").


explain analyze  update diffusion_2008_05_13 set state = 3001 where
state = 2101 and next_try_channel like 'FTP' and next_try_key like
'uatos_a+host_atos_a+datos_a+21';

                                         QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Index Scan using indx_diffusion_2008_05_13_channel on
diffusion_2008_05_13  (cost=0.00..10.41 rows=1 width=7379) (actual
time=12.712..169200.761 rows=48041 loops=1)
   Index Cond: ((state = 2101) AND ((next_try_channel)::text ~=~
'FTP'::text) AND ((next_try_key)::text ~>=~ 'uatos'::text) AND
((next_try_key)::text ~<~ 'uatot'::text))
   Filter: (((next_try_channel)::text ~~ 'FTP'::text) AND
((next_try_key)::text ~~ 'uatos_a+host_atos_a+datos_a+21'::text))


Euh, désolée, j'ai posé la question trop rapidement... La prochaine fois
je détaillerai méticuleusement le plan d'exécution avant de poster...

Merci encore, Valérie.


Le vendredi 16 mai 2008 à 12:24 +0000, Valérie SCHNEIDER a écrit :
> Rebonjour,
> Je crois que je me suis mal exprimée : le comportement que je voudrais
> comprendre, c'est pourquoi, en exécutant plusieurs fois le même update
> (à la suite, l'un après l'autre, dans la même session psql), le temps
> d'exécution ne soit pas quasi-immédiat à partir du second update
> (puisque plus aucune ligne à updater et qu'on passe par l'index -ce que
> confirme les explain analyze).
> Valérie.
> 
> Le vendredi 16 mai 2008 à 09:15 +0000, Valérie SCHNEIDER a écrit :
> > Bonjour,
> > 
> > Nous observons un comportement curieux d'une série d'update sur une base
> > PG. Je suis preneur d'explication si vous en avez ...
> > 
> > Voilà : il s'agit d'une base PG 8.3.1 sur serveur linux RedHat 5.1 64
> > bit avec 4 Go de RAM :
> > 
> > Date: mer mai 14 09:38:14 GMT 2008
> > Système Linux: Linux TDIFINTG 2.6.18-53.el5xen #1 SMP
> >                 Wed Oct 10 16:48:44 EDT 2007 x86_64 x86_64 x86_64
> > GNU/Linux
> > Redhat-Release: Red Hat Enterprise Linux Server release 5.1 (Tikanga)
> > Version Postgresql: 8.3.1
> > 
> > Au niveau de postgresql .conf :
> > # - Memory -
> > shared_buffers = 1024MB                 # min 128kB or
> > max_connections*16kB
> > 
> > # - Checkpoints -
> > checkpoint_segments = 10                # in logfile segments, min 1,
> > 16MB each
> > 
> > # pour les vacuum
> > maintenance_work_mem = 256MB            # min 1MB
> > 
> > # Pour les operations de tri
> > work_mem = 16MB                         # min 64kB
> > 
> > # memoire partagee utilisee par une transaction typique.
> > wal_buffers = 1024kB                    # min 32kB
> > 
> > autovacuum = off                       # enable autovacuum subprocess?
> > 
> > 
> > Un cron effectue des analyze sur les tables à intervalles choisis.
> > 
> > On effectue un update sur une table de 5 millions de lignes, de taille
> > environ 3Go, portant sur environ 50000 lignes, selon des critères
> > utilisant un index.
> > En exécutant plusieurs fois à la suite le même update (donc à partir du
> > second plus aucune ligne n'est mise à jour) on observe des temps très
> > longs pour finalement tomber à quelques millisecondes (qui est le
> > résultat attendu).
> > 
> > Que se passe-t'il d'après vous ?
> > 
> > 
> > Ci-dessous en pièce jointe la description de la table, des index, et une
> > série d'explain analyze update.
> > 
> > 
> > Merci !
> > Valérie.
> > 
> -- 
> 
> ********************************************************************
> *    Les points de vue exprimes sont strictement personnels et     *
> *      n'engagent pas la responsabilite de METEO-FRANCE.           *
> ********************************************************************
> * Valerie SCHNEIDER             Tel : +33 (0)5 61 07 81 91         *
> * METEO-FRANCE / DSI/DEV        Fax : +33 (0)5 61 07 81 09         *
> * 42, avenue G. Coriolis        Email : Valerie(dot)Schneider(at)meteo(dot)fr *
> * 31057 TOULOUSE Cedex 1 - FRANCE         http://www.meteo.fr      *
> ********************************************************************
> 
> 
-- 

********************************************************************
*    Les points de vue exprimes sont strictement personnels et     *
*      n'engagent pas la responsabilite de METEO-FRANCE.           *
********************************************************************
* Valerie SCHNEIDER             Tel : +33 (0)5 61 07 81 91         *
* METEO-FRANCE / DSI/DEV        Fax : +33 (0)5 61 07 81 09         *
* 42, avenue G. Coriolis        Email : Valerie(dot)Schneider(at)meteo(dot)fr *
* 31057 TOULOUSE Cedex 1 - FRANCE         http://www.meteo.fr      *
********************************************************************