Kolommen die worden gebruikt voor filteren of meedoen (of, in mindere mate, sorteren ) zijn interessant voor indexering. Kolommen die zojuist zijn geselecteerd, zijn nauwelijks relevant!Voor de volgende zoekopdracht indexeert alleen op a en e kan handig zijn:
SELECT a,b,c,d
FROM tbl_a
WHERE a = $some_value
AND e < $other_value;
Hier, f en mogelijk c zijn ook kandidaten:
SELECT a,b,c,d
FROM tbl_a
JOIN tbl_b USING (f)
WHERE a = $some_value
AND e < $other_value
ORDER BY c;
Test na het maken van indexen of ze echt nuttig zijn met EXPLAIN ANALYZE
. Vergelijk ook uitvoeringstijden met en zonder de indexen. Het verwijderen en opnieuw aanmaken van indexen gaat snel en eenvoudig. Er zijn ook parameters om experimenten
met EXPLAIN ANALYZE
. Het verschil kan enorm zijn of niet bestaan.
Omdat uw tabellen alleen-lezen zijn, is indexonderhoud goedkoop. Het is slechts een kwestie van schijfruimte.
Als je echt wilt weten wat je doet, begin met het lezen van de documenten .
Als u niet weet welke vragen u kunt verwachten...
-
Probeer voldoende query's te loggen om typische gebruiksscenario's te vinden. Log query's met de parameter
log_statement = all
daarom. Of log gewoon langzame zoekopdrachten in metlog_min_duration_statement
. -
Maak indexen dat kan handig zijn en controleer na enige tijd de statistieken om te zien wat er daadwerkelijk wordt gebruikt. PostgreSQL heeft een hele infrastructuur voor controlestatistieken . Een handige manier om statistieken (en vele andere taken) te bestuderen is pgAdmin waar u uw tabel / functie / index kunt kiezen en alle gegevens kunt ophalen op het tabblad "statistieken" in de objectbrowser (hoofdvenster).
-
Ga verder zoals hierboven beschreven om te zien of indexen die in gebruik zijn de zaken daadwerkelijk versnellen.
-
Als de queryplanner ervoor kiest om een of meer van uw indexen te gebruiken, maar dit heeft geen of nadelig effect, dan is er waarschijnlijk iets mis met uw instellingen en moet u de basis van prestatie-optimalisatie:vacuüm, analyse, kostenparameters, geheugengebruik, ...