PostgreSQL hierarchisch geschachtelte Menge riesige Datenbank

Question

Ich habe eine Datenbank, die Tausende von Szenarien speichern muss (jedes Szenario mit einem einzigen Unix_Zeitstempel Wert). Jedes Szenario hat 1.800.000 Register, die in einer Nested-Set-Struktur organisiert sind. Die allgemeine Tabellenstruktur ist gegeben durch:

table_skeleton: 
- unix_timestamp integer 
- lft integer 
- rgt integer 
- value 

Normalerweise meine SELECTs wird durchführen, sind alle verschachtelten Werte innerhalb eines bestimmten Szenarios nehmen, bedeutet dies zum Beispiel:

SELECT * FROM table_skeleton WHERE unix_timestamp = 123 AND lft >= 10 AND rgt <= 53 

Also meine Tabelle I hierarchisch gegliedert in Master/Kinder in Gruppen von Daten, zum Beispiel:

table_skeleton_201303 inherits table_skeleton: 
- unix_timestamp integer 
- lft integer 
- ... 

und

table_skeleton_201304 inherits table_skeleton: 
- unix_timestamp integer 
- lft integer 
- ... 

Und auch für die einzelne Kinder erstellten Index der üblichen Suche nach mir erwarte, ist es zum Beispiel:

Create Index idx_201303 
on table_skeleton_201303 
using btree(unix_timestamp, lft, rgt) 

Es das Abrufen verbessert, aber es dauert noch ca. 1 Minute für jedes wählen. Ich stellte mir vor, dass dies, weil der Index zu groß war immer in den Speicher geladen werden, so habe ich versucht, für jeden Zeitstempel Teilindex zu erstellen, zum Beispiel:

Create Index idx_201303_1362981600 
on table_skeleton_201303 
using btree(lft, rgt) 
WHERE unix_timestamp = 1362981600 

in der Tat und der zweite Typ von Index erstellt ist viel viel, viel kleiner als der allgemeine. Wenn ich jedoch eine EXPLAIN-ANALYSE für die SELECT-Anweisung ausführe, die ich zuvor hier gezeigt habe, ignoriert der Abfrage-Solver meinen neuen Teilindex und verwendet weiterhin den riesigen alten Index.

Gibt es einen Grund dafür? Gibt es einen neuen Ansatz zur Optimierung solcher hierarchischen Datenbanken mit großen verschachtelten Mengen?

Answer 1

Wenn Sie auf einem Tisch filtern, indem Field_A> x und Field_B> y, dann wird ein Index für field_a, field_b (nur tatsächlich kann, abhängig von der Verteilung und dem Prozentsatz der Zeilen mit Field_A> x, gemäß den Statistiken gesammelt) wird nur für "field_a> x" verwendet, und field_b> y wird eine sequenzielle Suche sein.

Im obigen Fall zwei Indices, eine für jedes Feld verwendet werden könnte, und jeder der Ergebnisse verbunden sind, die interne Äquivalent:

SELECT * 
FROM table t 
JOIN (
    SELECT id table field_a > x) ta ON (ta.id = t.id) 
JOIN (
    SELECT id table field_b > y) tb ON (tb.id = t.id); 

eine Änderung Es ist man von einem GIST profitieren könnten Index und Behandlung Ihrer LGT und RDT Felder als Punkte:

CREATE INDEX ON table USING GIST (unix_timestamp, point(lft, rgt)); 

SELECT * table 
WHERE unix_timestamp = 123 AND 
     point(lft,rgt) <@ box(point(10,'-inf'), point('inf',53));