Zur Semantik der Statistik "table scans (long tables)"

Der aktuelle Beitrag im Scratchpad von Jonathan Lewis hat ein wenig an seine alten Quiz-Night Artikel angeschlossen und mir eine Erwähnung eingetragen:

Martin Preiss (see comments) has been working hard to investigate this, and managed to produce a couple more variations in statistics for 'the same' problem.

Ganz so hart war die Arbeit nicht, aber überraschend war das Ergebnis für mich allemal. Interessant ist zunächst, dass sich zwar Angaben für die Statistiken "table scans (short tables)" und "table scans (long tables)" wechselseitig ausschließen (soll heißen: ein full table scan kann nicht gleichzeitig in beiden Kategorien erscheinen), dass das aber nicht für die übrigen "table scans"-Angaben gilt: also für "table scans (rowid ranges)", "table scans (cache partitions)" und "table scans (direct read)". Dort auftretende Ergebnisse erscheinen zusätzlich auch unter "table scans (short tables)" oder "table scans (long tables)" - sie sind also eher ergänzende Typ-Informationen. Interessant ist darüber hinaus, dass die Semantik der Angaben in "table scans (short tables)" und "table scans (long tables)" auch deutlich von dem abweicht, was zumindest ich mir bisher darunter vorgestellt hatte: für einen parallelisierten Zugriff erscheint hier nicht etwa ein Wert 1 und auch nicht die Anzahl der parallelen Slaves, sondern "Parallelisierungsgrad" * 13, wobei die 13 dem Parameter _px_min_granules_per_slave entspricht und die Anazhl der Chunks angibt, in die die Tabelle zerlegt wurde. Die entsprechende Angabe wiederholt sich in "table scans (rowid ranges)", und die zugehörige Aussage der Dokumentation hatte mich erst auf die Idee gebracht, die Frage der Parallelisierung zu prüfen: "During parallel query, the number of table scans conducted with specified ROWID ranges". Der Wert "Parallelisierungsgrad" * 13 erscheint übrigens auch im sql monitor Ergebnis unter "execs". Unschön daran ist, dass dadurch der Aussagewert von "table scans (long tables)" dadurch ziemlich überschaubar wird, sofern man sich nicht die Mühe macht, die Parallelisierung von Queries einzurechnen. Interessant ist weiterhin der Hinweis auf eine Option, die mir entweder entgangen oder entfallen war: parallele Slaves können in 11g den Buffer Cache verwenden, so dass sie nicht unter "table scans (direct read)" erscheinen müssen - während mir der umgekehrte Fall der serial full table scans mit direct path Nutzung schon häufiger begegnet ist, hatte ich diese Variante bisher nicht im Blick; fast vielleicht damit zusammen hängt, dass mich parallele Zugriffe regelmäßig in Erstaunen versetzen.