Re: Problème de select suivant un update

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>