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

Re: Problème de selectsuivant un update

From: Valérie SCHNEIDER <valerie(dot)schneider(at)meteo(dot)fr>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: pgsql-fr-generale <pgsql-fr-generale(at)postgresql(dot)org>,Pierre <pierre(dot)dupre(at)meteo(dot)fr>
Subject: Re: Problème de selectsuivant un update
Date: 2008-06-04 07:37:36
Message-ID: 1212565056.4247.80.camel@nazar.meteo.fr (view raw or flat)
Thread:
Lists: pgsql-fr-generale
Le mardi 03 juin 2008 à 23:49 +0200, Guillaume Lelarge a écrit :
> Valérie SCHNEIDER a écrit :
> > [...]
> > 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 ?
> > 
> 
> Personnellement, ça ne me choque pas outre mesure, mais je n'ai 
> peut-être pas assez d'infos pour comprendre.
Dans mon premier mail j'ai mis la description de la table et des index,
je les remets ci-dessous :
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=> 

La taille de la table sur disque est de 3 Go pour 5 millions de lignes
(en moyenne 700 octets par ligne).

L'update porte sur 70000 lignes et met un certain temps. Le problème
pour moi n'est pas là. Ce qui me dérange, c'est qu'ensuite, lorsque je
fais un accès select à la table sur ces mêmes lignes qui viennent d'être
mises à jour, avec les mêmes conditions, donc un select qui ramènera 0
ligne, et qui passe par l'index, cet accès devrait être immédiat, or il
met un temps catastrophique (de l'ordre de 300s) ! Si je relance le même
select (sur le même paquet de lignes), là le comportement sera celui
attendu : résultat quasi immédiat.
Le problème semble bien porter sur les lignes qui viennent d'être mises
à jour. Un select du même type (utilisant l'index) et portant sur un
autre paquet de lignes, sera rapide (<1s).

C'est réellement un pb pour nous. On est en train de mettre en place une
base à changement d'état, des tables journalières contenant 5 millions
de lignes, chacune sera mise à jour 2 fois dans la journée en moyenne,
donc 10 millions d'update par jour; en permanence une tâche recherchera
des lignes dans un état donné, donc ce que l'on teste reflétera ce que
l'on cherche à mettre en opérationnel.

Remarque : sur la même machine on a fait une base oracle (10g)
identique, et exécuté les mêmes instructions : le temps d'update est
comparable, le select qui suit est immédiat.
> 
> 1. Avant mise à jour, quel temps met cette requête à s'exécuter ?
> 2. Quelle est la taille de la table et de l'index ? (taille physique,
>     pas le nombre de lignes)
> 3. Comment est construit l'index ? (à priori, je suppose qu'il utilise
>     trois colonnes (state, channel, clef)
> 4. Avez-vous essayé de lancer un ANALYZE entre l'UPDATE et le SELECT ?
>     Pourriez-vous le faire et nous indiquer ce que cela donne ?

Autre test :
1. un select sur un paquet de lignes toujours en passant par index (on
fait toujours un explain analyze pour en être sûr) -> comportement
normal (réponse immédiate)
2. update sur ce même paquet de lignes -> un certain temps, supposé
normal (900 s)
3. analyse verbose de la table -> 21s
4. le select sur le même paquet de lignes (qui viennent d'être
modifiées) donc remonte 0 ligne -> 419 s !!!! 
5. un second select sur le même paquet de lignes (donc remonte 0 ligne)
-> immédiat

Voir le détail des explain analyze de cette séquence dans le fichier
joint.

Merci, Valérie.

> 
> Cordialement.
> 
> 
-- 

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

Attachment: exemple_update.ccf.20080604.sql
Description: text/x-sql (3.9 KB)

In response to

Responses

pgsql-fr-generale by date

Next:From: Guillaume LelargeDate: 2008-06-04 08:43:22
Subject: Re: Problème de select suivant un update
Previous:From: Sébastien DinotDate: 2008-06-03 23:10:42
Subject: Re: Ca?==?iso-8859-15?Q?lcul de médiane

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