De planner besluit niet om een bepaalde join-strategie te gebruiken op basis van diepzinnig redeneren, maar construeert eenvoudig alle mogelijke join-strategieën, schat de kosten in en kiest de goedkoopste.
Dat gezegd hebbende, zijn geneste lus-joins meestal de beste keuze als de buitenste tabel klein is, zodat de binnenste lus niet vaak hoeft te worden uitgevoerd. Ook kan een index op de join-voorwaarde van de binnenste tabel de kosten van een geneste lus-join aanzienlijk verlagen en er een aantrekkelijke strategie van maken.
In jouw geval is de slechte keuze te wijten aan een verkeerde inschatting:
Foreign Scan on wind_forecast_recent w (cost=... rows=1 ...) (actual ... rows=7 ...)
Dat zorgt ervoor dat de binnenste lus 7 keer wordt uitgevoerd in plaats van één keer, zodat de uitvoeringstijd 70 seconden is in plaats van 10.
U moet tabelstatistieken verzamelen op wind_forecast_recent :
ANALYZE wind_forecast_recent;
Onthoud dat automatische analyse niet . doet buitenlandse tafels behandelen; daar moet je zelf voor zorgen.
Als dat niet werkt, kunt u proberen de use_remote_estimate in te stellen optie op de vreemde tafel en zorg ervoor dat de tabelstatistieken correct zijn in de externe database.