Ist technisch erst möglich wenn zum Zeitpunkt der Planerstellung der Optimizer Kenntnis über die Verteilung der Daten hat. Aktuell gibt es diese Information nicht, sondern es wird banal gesagt derzeit alles über den Selektivitäts-Kamm eines Index geschert. Mit der Einführung der Speicherung von Histogrammdaten für Indizes schauts dann anders aus. Hier hat dann der Optimizer zur Prepare-Time viel mehr Möglichkeiten.
Ein extremeres Beispiel ist mit einem Boolean-Feld. Angenommen wir haben eine große Tabelle (> 1 Mio Datensätze) wo nur ein Datensatz den Wert FALSE beinhaltet. Die Verwendung eines Index für die Suche nach TRUE wird in der Regel immer langsamer sein als ein Full-Table Scan, weil für den Zugriff zum eigentlichen Datensatz immer doppelt gemoppelt wird, sprich Index Page laden, Lookup des Datensatzes = Data Page laden. Abfrage des einen Datensatzes mit FALSE siehts natürlich ganz anders aus. Bei der Mitführung eines Histogramms würde der Optimizer wissen, dass 999999 Einträge TRUE speichern und 1er FALSE. Dieses Wissen kann sich dann der Optimizer zu nutze machen, dass je nach Abfrageprofil ein Index verwendet wird oder auch nicht.
Siehe auch:
http://tracker.firebirdsql.org/browse/CORE-1686
Ursprünglich für Firebird 3 geplant, aber aktuell für V3 rausgenommen.