Hash-Join mit IN-Klausel und Unterabfrage in Spanner vermeiden

Ich habe das folgende Abfrageoptimierungsproblem in Spanner, und hoffe, dass es einen Trick gibt, den ich vermisse, der mir helfen wird, den Abfrageplaner zu meinem Willen zu biegen.

Hier ist das vereinfachte Schema:

Und eine Abfrage mit einer Unterabfrage in einer IN -Klausel:

Dies erzeugt einen 10-Elemente-Satz über einen Hash-Join von T0 gegen die Ausgabe der Unterabfrage:

Beachten Sie, dass die Unterabfrage zwar komplex ist, aber tatsächlich eine sehr kleine Menge erzeugt. Unglücklicherweise scannt es auch die Gesamtheit von T1, um sie dem Hash-Join zuzuführen, was sehr langsam ist.

Wenn ich jedoch die Ausgabe der Unterabfrage in T1 nehme und sie manuell in die IN -Klausel schiebe:

Es ist dramatisch schneller, vermutlich, weil es den Index von T0 nur einmal pro Eintrag trifft und keinen Hash-Join für den gesamten Inhalt verwendet:

Ich könnte einfach zwei Abfragen ausführen, und das ist mein bisher bester Plan. Aber ich hoffe, dass ich einen Weg finden kann, Spanner dazu zu bringen, zu entscheiden, dass es das ist, was es mit der Ausgabe der Unterabfrage im ersten Beispiel machen soll. Ich habe alles ausprobiert, was mir einfällt, aber das kann in SQL überhaupt nicht ausgedrückt werden.

Auch: Ich habe das noch nicht ganz bewiesen, aber in manchen Fällen befürchte ich, dass die Ausgabe der 10-Elemente-Unterabfrage auf einige tausend Elemente explodieren könnte (T1 wird mehr oder weniger ohne Grenzen wachsen, leicht zu Millionen). Ich habe manuell mit ein paar hundert Elementen in der aufgeplusterten IN -Klausel getestet und es scheint akzeptabel zu funktionieren, aber ich bin ein wenig besorgt, dass es außer Kontrolle geraten könnte.

Beachten Sie, dass ich auch einen Join für die Unterabfrage ausprobiert habe:

Aber es hat etwas wirklich Schreckliches im Abfrageplaner getan, das ich hier nicht einmal versuchen werde zu erklären.