Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
Pages : 1
#1 01/02/2011 17:07:55
- genio
- Membre
Zone de tri Postgrès
Re-bonjour...
J'ai un prédicat qui consomme énormément car il attaque un index bidon en prod => OK
Cet ordre effectue un SELECT avec un ORDER BY toto DESC LIMIT 1 => OK
J'ai trouvé comment l'optimiser avec le rajout d'un index mais j'ai une question à vous poser :
Est-il possible d'agrandir la zone de tri de Postgrès ? Et quelle nom porte t'elle ?
Quelle taille minimale doit-on lui donner ?
Mes question sont un peu vagues mais j'aimerais avoir l'équivalent des pools de tri d'oracle ...
Merci pour vos réponses...
Hors ligne
#2 01/02/2011 17:38:12
- Marc Cousin
- Membre
Re : Zone de tri Postgrès
Il n'y a pas de pool, la mémoire est par processus. L'autre différence, c'est qu'elle est allouée et désallouée à la volée suivant les besoins des requêtes. C'est le paramètre work_mem dont il s'agit. C'est l'espace maximum de mémoire qu'UNE opération de tri ou de hachage peut prendre. Donc s'il y a plusieurs tris dans une requête, work_mem peut être alloué plusieurs fois. Mais il sera désalloué dès qu'il ne sera plus nécessaire.
De la même façon, les fichiers temporaires (quand la mémoire ne suffit plus) sont dynamiques, et créés et détruits à la volée.
Marc.
Hors ligne
#3 02/02/2011 17:39:23
- genio
- Membre
Re : Zone de tri Postgrès
Merci Marc pour votre réponse...
1°) Chez nous, la work_mem est à 500 méga ... cela veut-il dire que chaque process prend au minimum, 500 méga de mémoire à lui tout seul ?
2°) Comment faire un select non bloquant, qui lit donc les 'dirt' données ?
Hors ligne
#4 02/02/2011 17:44:33
- Marc Cousin
- Membre
Re : Zone de tri Postgrès
1) Non, la work_mem n'est allouée qu'au besoin, et libéré juste après. Mais 500Mo est gigantesque, à part pour un infocentre. On met plutôt entre 1 et 10Mo pour l'OLTP.
2) Je ne suis pas sûr de comprendre la question. Je préférerais que vous précisiez.
Marc.
Hors ligne
#5 02/02/2011 18:01:52
- genio
- Membre
Re : Zone de tri Postgrès
Imaginons un traitement qui effectue des inserts sur la tableA => OK
Imaginons qu'au même moment j'envoie un 'select * from tableA' => OK
Qu'est-ce qu'il se passe ?
Hors ligne
#6 02/02/2011 18:04:38
- gleu
- Administrateur
Re : Zone de tri Postgrès
Le SELECT n'est pas bloqué par l'INSERT et inversement.
Guillaume.
Hors ligne
#7 02/02/2011 18:17:51
- genio
- Membre
Re : Zone de tri Postgrès
Ok mais si c'est un select * from tableA avec un ORDER BY toto DESC LIMIT OFFSET 1cela bloque t'il ?
Hors ligne
#8 02/02/2011 18:23:53
- gleu
- Administrateur
Re : Zone de tri Postgrès
Non, quelque soit le SELECT.
Guillaume.
Hors ligne
#9 02/02/2011 18:40:18
- genio
- Membre
Re : Zone de tri Postgrès
Imaginons plusieurs 'Select * ... ORDER BY toto DESC LIMIT 1' simultanés => OK
Si tous les select prennent 500 méga de mémoire, il se peut que le serveur soit saturé très vite non ?
Hors ligne
#10 02/02/2011 18:41:37
- Marc Cousin
- Membre
Re : Zone de tri Postgrès
Oui, c'est bien pour ça que votre paramètre est bien trop gros, comme écrit dès le début 
Par contre, il ne va pas allouer 500Mo si il y a 10Mo à trier.
Marc.
Hors ligne
#11 02/02/2011 18:45:54
- genio
- Membre
Re : Zone de tri Postgrès
Merci pour vos réponses...
Hors ligne
Pages : 1