Vous n'êtes pas identifié(e).
La seule raison que je vois est que le INSERT de 18 secondes se fait de façon séquentielle en bout de fichier et que celui de 267 secondes se fait de façon aléatoire à cause des multiples trous dans la table. Cela étant dit, cette "raison" ne me plait pas du tout.
Guillaume.
Hors ligne
Je pense qu'après le delete massif et vacuum analyze, il y a un problème de données en cache ou quelque chose de ce genre (je ne vois pas d'autre explication logique):
Subquery Scan "*SELECT*" (cost=7200.00..7690.00 rows=4000 width=400) (actual time=294.598..714.618 rows=40000 loops=1)
-> HashAggregate (cost=7200.00..7640.00 rows=4000 width=392) (actual time=294.586..592.264 rows=40000 loops=1)
-> Seq Scan on table_minute_1102221935 (cost=0.00..2400.00 rows=40000 width=392) (actual time=0.014..22.726 rows=40000 loops=1)
Total runtime: 267104.377 ms
Ne colle pas. Le plan d'exécution dit que l'opération de SELECT dure 714ms. Si on met réellement 267s, c'est qu'il faut 266 secondes pour l'insertion de 40000 enregistrements, ce qui est un chiffre démentiel, même si les données ne sont pas en cache.
Marc.
Hors ligne
Ok merci.
Bah ce que je vais faire, c'est repartir sur une base vide avec cette nouvelle politique de delete/vacuum/analyse et voir si je reproduit le problème.
Sinon il est peut être possible que je mette le vacuum sur la table en question en "verbose" et analyser ce qu'il dit ? Ca donnera peut être des pistes.
Hors ligne
Oui, peut-être que vacuum aura quelque chose à nous dire. Au passage, vous êtes en 8.2. Êtes vous sûr que votre max_fsm_pages soit suffisamment grand ?
Marc.
Hors ligne
J'ai max_fsm_pages = 1000000
et max_fsm_relations = 2000
J'ai environ 1200 objets dans ma base.
J'avais positionné ces valeurs avec Guillaume l'année dernière.
Hors ligne
