| 525 | | différents types de jointures. |
|---|
| 526 | | Les requêtes coûteuses sont évalués et basé sur des statistiques du planificateur recueillies quand les tables |
|---|
| 527 | | sont analysées et combiner avec l'ajustements des coûts du planificateur, et les fonctionnalités avancées tel que le |
|---|
| 528 | | "Genetix Query Optimizer" permettant l'optimisation efficace de jointûres très compliqués. |
|---|
| | 525 | différents types de jointures. Les requêtes coûteuses sont évalués et basé sur des statistiques du planificateur |
|---|
| | 526 | recueillies quand les tables sont analysées et combiner avec l'ajustements des coûts du planificateur, et les |
|---|
| | 527 | fonctionnalités avancées tel que le "Genetix Query Optimizer" permettant l'optimisation efficace de jointûres très |
|---|
| | 528 | compliqués. |
|---|
| 554 | | |
|---|
| 555 | | |
|---|
| | 554 | La définition de l'ordre d'exécution fourni plusieurs comparaisons entre différences de traîtement des requêtes par les |
|---|
| | 555 | deux bases de données. Comme son optimisation automatique est plus robuste, PostgreSQL réalise généralement un meilleur |
|---|
| | 556 | travail avec les jointures compliquées que MySQL -- Mais seulement si le planificateur est configuré correctement |
|---|
| | 557 | (définir une valeur trop petite pour effective_cache_size est une erreur commune) et que les statistiques sur les |
|---|
| | 558 | tables sont maintenues à jour (typiquement via auto-vacuum). Le fait que vous deviez donner à l'optimiseur de PostgreSQL |
|---|
| | 559 | des informations correctes sur lesquelles travailler, est quelque chose de controversé dans le choix de conception. |
|---|
| | 560 | Les développeurs principaux de PostgreSQL estiment qu'il est plus important de se concentrer sur l'amélioration de |
|---|
| | 561 | l'optimiseur pour qu'il fonctionne correctement dans tous les cas plutôt que d'autoriser les requêtes à introduire des modification dans le plan comme contournement aux problèmes. |
|---|
