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

Re: Problème de select suivant un update

From: Alain <eurlix(dot)alain(at)free(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Problème de select suivant un update
Date: 2008-06-03 17:17:32
Message-ID: 20080603191732.8c6821ed.eurlix.alain@free.fr (view raw or flat)
Thread:
Lists: pgsql-fr-generale
On Tue, 03 Jun 2008 13:41:13 +0000
Valérie SCHNEIDER <valerie(dot)schneider(at)meteo(dot)fr> wrote:

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


Valérie,

Essayez en faisant un VACUUM après mises à jour et avant select.
Si ça améliore les performances, lisez la doc sur vacuum.

AMHA, toutes les BD privilégient le conversationnel et les index sont mis à jour
avec un certain délai, ce qui n'est pas grâve à la vitesse de saisie manuelle.
Mais je ne pense pas que vos 70 000 mises à jour soient faites une par une ?  

Amicalement,
-- 
Alain <eurlix(dot)alain(at)free(dot)fr>

In response to

pgsql-fr-generale by date

Next:From: Guillaume LelargeDate: 2008-06-03 21:49:00
Subject: Re: Problème de select suivant un update
Previous:From: Valérie SCHNEIDERDate: 2008-06-03 13:41:13
Subject: Problème de select suivant un update

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