Re: Problème de select suivant 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 select suivant un update
Date: 2008-06-04 07:37:36
Message-ID: 1212565056.4247.80.camel@nazar.meteo.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
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 Content-Type Size
exemple_update.ccf.20080604.sql text/x-sql 3.9 KB

In response to

Responses

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Guillaume Lelarge 2008-06-04 08:43:22 Re: Problème de select suivant un update
Previous Message Sébastien Dinot 2008-06-03 23:10:42 Re: Calcul de médiane