PostgreSQL
La base de données la plus sophistiquée au monde.

Ouverture de session

Navigation

Contactez-nous

Administration du site :
"equipe chez postgresqlfr point org"

Contact presse :
"fr chez postgresql point org"

Contact association :
"bureau chez postgresqlfr point org"

Questions PostgreSQL :
 IRC :
  serveur irc.freenode.net
  canal #postgresqlfr

Recherche

Accéder aux archives

« Octobre 2008  
Lun Mar Mer Jeu Ven Sam Dim
  2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  

Syndication

Flux XML

Sondage

Quelle est la version de PostgreSQL la plus répandue sur vos serveurs ?
8.3
10%
8.2
42%
8.1
40%
8.0
2%
7.4
6%
7.3 ou antérieure
0%
Nombre de votes: 48

Optimisation 13M de select

Technique - optimisation | Optimisation 13M de select

Par pauls le 31/07/2008 - 15:15

Bonjour,

J'ai une base de données contenant 13M de lignes dans une table A
Je dois les traités une par une puis insérer les resultats dans une autre table B
Mais plus je fais de traitement plus la récupartion de la prochaine ligne a traiter est longue.

Pour ca j'utilise un script python dont le principe est :

TANT QUE "SELECT * FROM tableA WHERE traite=0 LIMIT 1" retourne une ligne :
je fais des calculs
si le resultat est bon :
| j'essaye de trouver une autre ligne "AMIE" dans A qui correspond a certain criteres ( et en plus traite IN (0, 2) )
| si j'en trouve une => UPDATE tableA SET traite = 1 WHERE id = id_de_la_ligne_amie
| je rassemble les donnes des 2 lignes
| j'insert la nouvelle ligne obtenue dans B
| UPDATE tableA SET traite = 1 WHERE id = id_ligne
sinon
| UPDATE tableA SET traite = 2 WHERE id = id_ligne
fin si

Quand je chercher une ligne "AMIE" si j'en trouve une je dois la marqué comme traité dans la tablea A du coup je suis obligé de faire un "LIMIT 1".
Aprés mesure de toutes les parties du code, je remarque que le SELECT principal prends 0.005421sec la premiere fois, mais augement de 6e-7sec à chaque itération.
Vous allez me dire que c'est ridicule mais si on calcul ca veux dire que le traitement de mes 13M d'enregistrements se finira dans 596J....
Si le select n'augmentait pas le traitement des 13M de lignes aurait fini en 20h ...

exemple sur 19000 lignes les 10premiers SELECT:
main.py@245: select query_time: 0.00148892402649 sec
main.py@245: select query_time: 0.0016028881073 sec
main.py@245: select query_time: 0.00145816802979 sec
main.py@245: select query_time: 0.00147581100464 sec
main.py@245: select query_time: 0.0014431476593 sec
main.py@245: select query_time: 0.00145602226257 sec
main.py@245: select query_time: 0.0016040802002 sec
main.py@245: select query_time: 0.0014488697052 sec
main.py@245: select query_time: 0.00161480903625 sec
et les 10 derniers:
main.py@245: select query_time: 0.0167269706726 sec
main.py@245: select query_time: 0.0167100429535 sec
main.py@245: select query_time: 0.016508102417 sec
main.py@245: select query_time: 0.0166959762573 sec
main.py@245: select query_time: 0.016743183136 sec
main.py@245: select query_time: 0.0171461105347 sec
main.py@245: select query_time: 0.0165591239929 sec
main.py@245: select query_time: 0.0167860984802 sec
On voit nettement une augmentation

J'ai essayer tous les 100 000 lignes de refaire un vacuum full analyze tableA mais ca ne change rien

Mon serveur a 16Go de ram, la table fait 13Go, y a rien d'autre qui tourne sur le serveur appart pgsql 8.1.11 (debian stable)
voici ca config:
shared_buffers = 100000
temp_buffers = 100000
work_mem = 512000
maintenance_work_mem = 1048576
max_fsm_pages = 41522880
max_fsm_relations = 8000

Pourquoi le SELECT augmente ? Et surtout comment faire pour ne pas que ca augmente ?

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur "Sauvegarder les paramètres" pour activer vos changements.

Parcours séquentiels

SAS/ = 4 Août, 2008 - 17:52

Bonjour,

Le problème de votre traitement est que vous semblez imposer un parcours séquentiel de la table *à chaque requête*.

Avez-vous seulement un index sur "traite", si oui, est-il fonction de la valeur de la colonne ?

Librement,
Stéphane Schildknecht
Dalibo
PostgreSQLFr


© PostgreSQLFr, tous droits réservés.
Site déclaré à la CNIL sous le numéro 1074678, conformément à la Loi en vigueur.