Re: [pgsql-fr-generale] Problème d'update : résolu !!!

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.Schneider@meteo.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.Schneider@meteo.fr *
* 31057 TOULOUSE Cedex 1 - FRANCE

http://www.meteo.fr

*
********************************************************************

--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale