PostgreSQL SELECT DISTINCT
Leistungsengpässe und Optimierungsstrategien
Eine SELECT DISTINCT
-Abfrage in einer PostgreSQL-Tabelle mit fast zwei Millionen Datensätzen weist eine unerwartet langsame Leistung auf (500–600 ms). Der Abfrageplaner verwendet aus unerklärlichen Gründen standardmäßig einen sequentiellen Scan, anstatt einen verfügbaren Index zu nutzen, und selbst die Indexerzwingung verbessert die Ausführungszeit nicht wesentlich.
Emulierung des Index-Skip-Scans in PostgreSQL
Da PostgreSQL über keine native Funktion zum Überspringen von Indexscans verfügt, kann eine Problemumgehung mithilfe eines rekursiven allgemeinen Tabellenausdrucks (CTE) das Verhalten nachahmen. Dieser CTE ruft iterativ unterschiedliche Produkt-IDs in aufsteigender Reihenfolge ab und nutzt zur Effizienz einen Index für product_id
:
<code class="language-sql">WITH RECURSIVE cte AS ( ( SELECT product_id FROM tickers ORDER BY 1 LIMIT 1 ) UNION ALL SELECT l.* FROM cte c CROSS JOIN LATERAL ( SELECT product_id FROM tickers t WHERE t.product_id > c.product_id ORDER BY 1 LIMIT 1 ) l ) SELECT * FROM cte;</code>
Dieser Ansatz bietet einen erheblichen Leistungsgewinn im Vergleich zu einem vollständigen Tabellenscan.
Alternative Ansätze: DISTINCT
und DISTINCT ON
Für Tabellen mit einer gleichmäßigeren Verteilung der Zeilen pro eindeutiger Produkt-ID erweisen sich die Standardschlüsselwörter DISTINCT
oder DISTINCT ON
möglicherweise als schneller als der emulierte Index-Skip-Scan. Ihre Leistung hängt stark von der Datenverteilung ab.
Zukünftige Verbesserungen: Scan des nativen Index überspringen
Die PostgreSQL-Entwicklung umfasst fortlaufende Arbeiten zur Integration nativer Index-Skip-Scan-Funktionen. Diese zukünftige Verbesserung verspricht weitere Leistungsoptimierungen für SELECT DISTINCT
Abfragen.
Das obige ist der detaillierte Inhalt vonWarum ist meine PostgreSQL SELECT DISTINCT-Abfrage so langsam und wie kann ich ihre Leistung verbessern?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!