PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#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 smile

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

Pied de page des forums