Warum ist mein PostgreSQL „SELECT DISTINCT' so langsam und wie kann ich es beheben?

PostgreSQL SELECT DISTINCT Leistungsengpass: Eine Fallstudie

In diesem Artikel werden Leistungsprobleme untersucht, die bei einer SELECT DISTINCT Abfrage einer PostgreSQL-Tabelle mit etwa zwei Millionen Datensätzen auftreten.

Kontext

In der tickers-Tabelle werden Daten aus dem „Ticker“-Kanal von Coinbase Pro gespeichert. Ein zusammengesetzter Primärschlüssel enthält die Spalte product_id.

Leistungsproblem

Es wurde erwartet, dass die Abfrage SELECT DISTINCT product_id FROM tickers aufgrund des Index für product_id eine gute Leistung erbringen würde. Die Ausführung dauerte jedoch durchweg 500–600 Millisekunden.

Abfrageplanuntersuchung

EXPLAIN ANALYZE zeigte, dass der Abfrageplaner standardmäßig einen sequentiellen Scan durchführte und den Index product_id ignorierte. Durch das Erzwingen der Indexverwendung konnte das Leistungsproblem nicht behoben werden.

Indexoptimierungsversuche

Das Erstellen eines dedizierten Index für product_id brachte nur geringfügige Verbesserungen, wobei sequentielle Scans vom Planer immer noch bevorzugt werden, sofern sie nicht explizit überschrieben werden.

Effektive Lösung: Index-Skip-Scan-Emulation

Die implementierte Lösung emuliert Index-Skip-Scans mithilfe rekursiver Abfragen mit seitlichen Verknüpfungen. Dieser Ansatz verbesserte die Leistung erheblich und reduzierte die Ausführungszeit selbst bei einem Datensatz von 2,25 Millionen Zeilen auf 0,75 Millisekunden.

Zusammenfassung

Der derzeitige Mangel an nativen Index-Skip-Scan-Funktionen in PostgreSQL wird durch diese Emulationstechnik behoben. Diese Methode nutzt effektiv vorhandene Indizes und vermeidet die Leistungseinbußen sequenzieller Scans für SELECT DISTINCT Abfragen in großen Tabellen.

Das obige ist der detaillierte Inhalt vonWarum ist mein PostgreSQL „SELECT DISTINCT' so langsam und wie kann ich es beheben?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!