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

Problème de select suivant un update

From: Valérie SCHNEIDER <valerie(dot)schneider(at)meteo(dot)fr>
To: pgsql-fr-generale <pgsql-fr-generale(at)postgresql(dot)org>
Subject: Problème de select suivant un update
Date: 2008-06-03 13:41:13
Message-ID: 1212500473.4247.17.camel@nazar.meteo.fr (view raw or flat)
Thread:
Lists: pgsql-fr-generale
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(dot)Schneider(at)meteo(dot)fr *
* 31057 TOULOUSE Cedex 1 - FRANCE         http://www.meteo.fr      *
********************************************************************


Responses

pgsql-fr-generale by date

Next:From: AlainDate: 2008-06-03 17:17:32
Subject: Re: Problème de select suivant un update
Previous:From: Stéphane A. SchildknechtDate: 2008-05-27 16:27:39
Subject: Re: Drupal, CMS avec PG

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group