Aangezien je twee grote tabellen samenvoegt en er geen voorwaarden zijn die rijen kunnen uitfilteren, is de enige efficiënte join-strategie een hash-join, en geen enkele index kan daarbij helpen.
Eerst zal er een sequentiële scan zijn van een van de tabellen, waaruit een hash-structuur wordt opgebouwd, dan zal er een sequentiële scan zijn over de andere tafel, en de hash zal worden onderzocht voor elke gevonden rij. Hoe kan een index daarbij helpen?
U kunt verwachten dat zo'n operatie lang duurt, maar er zijn enkele manieren waarop u de operatie kunt versnellen:
-
Verwijder alle indexen en beperkingen op
tx_input1voordat je begint. Uw zoekopdracht is een van de voorbeelden waarbij een index helemaal niet helpt, maar in feite pijn doet prestaties, omdat de indexen samen met de tabel moeten worden bijgewerkt. Maak de indexen en beperkingen opnieuw nadat u klaar bent met deUPDATE. Afhankelijk van het aantal indexen op tafel, kun je een behoorlijke tot enorme prestatiewinst verwachten. -
Verhoog de
work_memparameter voor deze ene bewerking met deSETcommando zo hoog als je kunt. Hoe meer geheugen de hash-bewerking kan gebruiken, hoe sneller het zal zijn. Met zo'n grote tabel heb je waarschijnlijk nog steeds tijdelijke bestanden, maar je kunt nog steeds een behoorlijke prestatiewinst verwachten. -
Verhoog
checkpoint_segments(ofmax_wal_sizevanaf versie 9.6) naar een hoge waarde zodat er minder controlepunten zijn tijdens deUPDATEbediening. -
Zorg ervoor dat de tabelstatistieken in beide tabellen nauwkeurig zijn, zodat PostgreSQL een goede schatting kan maken van het aantal hash-buckets dat moet worden gemaakt.
Na de UPDATE , als het een groot aantal rijen beïnvloedt, kunt u overwegen om VACUUM (FULL) uit te voeren op tx_input1 om van de resulterende tafelzwelling af te komen. Hierdoor wordt de tafel voor een langere tijd vergrendeld, dus doe dit tijdens een onderhoudsperiode. Het zal de grootte van de tafel verkleinen en daardoor de opeenvolgende scans versnellen.