Bonjour,
Il y a quelques temps j'ai posté un mail sur un problème d'update mais
je me m'étais ensuite rendu compte d'une erreur dans nos tests.
Maintenant plus d'erreur, mais nous observons toujours un comportement
curieux -reproductible- d'une série d'update puis select 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.
On travaille sur une table de test contenant 5 millions de lignes. On
effectue un update portant sur environ 70000 lignes (avec utilisation
d'index). Lorsque on effectue ensuite un select portant sur les lignes
mises à jour (avec même condition donc on ne retournera aucune ligne)
le temps d'exécution de ce select est très long alors que on
s'attendrait à un retour immédiat.
Pourquoi ???
Ci-dessous les résultats des explain analyze update, select etc :
difmet=> \d test_update
Table « public.test_update »
Colonne | Type | Modificateurs
------------+-----------------------------+---------------
id | bigint | not null
state | integer | not null
state_date | timestamp without time zone | not null
priority | integer | not null
channel | character varying(30) | not null
clef | character varying(2048) | not null
data1 | character varying |
data2 | character varying |
data3 | character varying |
data4 | character varying |
Index :
« pk_test_update_id » PRIMARY KEY, btree (id)
« indx_test_update_channel » btree (state, channel
varchar_pattern_ops, clef varchar_pattern_ops, priority, state_date)
Contraintes de vérification :
« ck_test_update_id » CHECK (id > 0)
« ck_test_update_state » CHECK (state > 0)
difmet=>
difmet=> \timing
Chronométrage activé.
difmet=> \!date
mer mai 21 10:58:20 GMT 2008
difmet=> explain analyze update test_update set state = 3001 where
state
= 2101 and channel like 'FTP' and clef like
'ddbddbddbddbddbddbddbddbddbddbddbddbddbddbddb' ;
QUERY PLAN
--------------------------------------------------------------------------------------------
Index Scan using indx_test_update_channel on test_update
(cost=0.00..129127.15 rows=69744 width=572) (actual
time=22.140..327988.689 rows=71000 loops=1)
Index Cond: ((state = 2101) AND ((channel)::text ~=~ 'FTP'::text)
AND ((clef)::text ~=~
'ddbddbddbddbddbddbddbddbddbddbddbddbddbddbddb'::text))
Filter: (((channel)::text ~~ 'FTP'::text) AND ((clef)::text ~~
'ddbddbddbddbddbddbddbddbddbddbddbddbddbddbddb'::text))
Total runtime: 697914.820 ms
(4 lignes)
Temps : 698885,960 ms
difmet=> \!date
mer mai 21 11:09:59 GMT 2008
difmet=> explain analyse select id,priority,state_date from test_update
where state = 2101 and channel like 'FTP' and clef like
'ddbddbddbddbddbddbddbddbddbddbddbddbddbddbddb' LIMIT 10;
QUERY PLAN
----------------------------------------------------------------------------------------
Limit (cost=0.00..18.52 rows=10 width=20) (actual
time=258036.859..258036.859 rows=0 loops=1)
-> Index Scan using indx_test_update_channel on test_update
(cost=0.00..130964.52 rows=70734 width=20) (actual
time=258036.854..258036.854 rows=0 loops=1)
Index Cond: ((state = 2101) AND ((channel)::text ~=~
'FTP'::text) AND ((clef)::text ~=~
'ddbddbddbddbddbddbddbddbddbddbddbddbddbddbddb'::text))
Filter: (((channel)::text ~~ 'FTP'::text) AND ((clef)::text
~~
'ddbddbddbddbddbddbddbddbddbddbddbddbddbddbddb'::text))
Total runtime: 258036.916 ms
(5 lignes)
Temps : 262332,196 ms
difmet=> \!date
mer mai 21 11:14:22 GMT 2008
On voit bien que le select suivant l'update passe par l'index, que le
nombre de lignes concernées est 0, mais pourquoi le temps d'exécution de
ce select n'est-il pas quasi-nul ?
On a aussi fait le même test sur une version postgres 8.2, même
comportement.
Merci de votre aide, 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
*
********************************************************************
--
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
