L'optimiseur de toute base de données basée sur les coûts est toujours plein de surprises, et celui-ci n'est pas inhabituel sur les plates-formes im familier.
Quelques questions: - avez-vous créé des statistiques sur la table? (sinon vous volez en aveugle) - Quel est le type de données pour cette colonne? (J'espère que c'est un entier quelconque, pas un nombre (x, y), même si y = 0)
En outre: Les statistiques pour une colonne dans netezza ne contient aucune statistique de distribution (il ne saura pas s'il y a plus de cas «résolus» que de cas «non résolus» dans une table de système de soutien avec 5 ans de données). Il repose plutôt sur deux choses: 1) pour toutes les tables: statistiques simples si vous les créez (nombre de valeurs distinctes, valeurs max + min, nombre de zéros) 2) pour les tables de grande taille (je pense que la valeur minimale configurable est proche de 100 rangs), il crée une sytistique JIT (Just In Time) en analysant quelques pages de données aléatoires sur les fichiers de données qui correspondent à la zone mappable whereclauses et en créant des statistiques pour cette requête.
La dernière fonctionnalité est en fait assez puissante, même si elle ajoute du temps d'exécution à la phase de planification de la requête. Cela augmente considérablement la probabilité que s'il y a QUELQUE corrélation entre deux whereclauses sur une table, cela sera pris en compte. Un exemple: une fois sur (AGE> 60 et Retired = true) dans une liste de tous les citoyens d'une grande ville. Il est probablement plus ou moins pertinent d'ajouter la restriction AGE, et Netezza le saura. En général, vous ne devriez pas vous inquiéter du fait que le nombre estimé de lignes soit un peu nul (comme dans le cas présent) avec netezza, il sera le plus souvent "juste assez" et jettera du matériel sur le problème pour compenser les erreurs mineures . Jusqu'à récemment j'ai travaillé avec SQLserver qui est notorius (peut-être mieux dans une version plus récente) pour être trop optimiste sur la valeur des clauses where, et finir dans les plans d'accès avec 5 niveaux de jointures en boucle imbriquée avec des millions de lignes dans chaque, en rejoignant 6 tables.Si vous modifiez les clauses where comme vous l'avez fait dans la question, sqlserver mettra l'empathie LESS sur une restriction spécifique, ce qui peut rendre les 5 jointures plus efficaces, ce qui se traduira par de meilleures performances. D'après mon expérience, il est BEAUCOUP trop fréquent sur les bases de données qui dépendent trop fortement de ces estimations - peut-être parce que l'optimiseur n'a pas été créé/réglé pour une charge de travail semblable à celle d'un entrepôt.