Discussion :

[donnadieujulien]

Bonjour,

je cherche à optimiser les temps de traitement sur une base assez volumineuse.
En effet, cette base contient plus de 4000 schémas, 50 tables / schéma en moyenne et entre 5 et 10 champs par table.

Le nombre d'entrée est inconnu, mais cette base fait environ 6 gigas, ce qui n'est pas énorme en soit.

Donc le problème, c'est que la la moindre requête se transforme en véritable cauchemard.

J'ai essayé de modifier le paramètre shared buffers, avec une amélioration de 10/15 %. Mais c'est une goutte d'eau dans une botte de foin.

Quelqu'un aurait il une idée? de la doc?

pg : v 8.3.12

[xavier-Pierre]

Mais c'est une goutte d'eau dans une botte de foin.

le pire aurait été
une aiguille dans dans la mer

[donnadieujulien]

effectivement je ne suis pas multitache mdr

[SQLpro]

Quelle est la config du serveur :

• 32 ou 64 bits
• VM ou physique ?
• taille de la RAM
• taille et structure des disques (et niveau de RAID)

Mais aussi : pourquoi 4000 schémas SQL ?
Je redoute un problème de conception...

A +

[donnadieujulien]

il n'y a pas de serveur, postgres tourne sur la machine client en local.
Donc, l'architecture est fonction de l'OS du client, mais nos applications sont en 32 bits.
Donc pas de VM également, pas forcément de raid, ca dépend du client.

Le problème est indépendant de la machine.
Alors bien sur, une machine plus puissante aura un point de rupture plus grand mais ce n'est pas un problème de ressources.

En fait on dirait que postgress mets une plombe à initialiser la requete (il doit faire sa mouture avec ses tables internes), et une fois cela terminé la requete s'effectue très très vite.

Je me demande le sgbd est bien paramétré, parce que 4000 schemas, c'est sur que c'est lourd, mais les concepteurs n'ont t'ils rien prévu pour limiter la casse?