Shoaib Burq (VPAC) wrote:
Just tried it with the following changes:
shared_buffers = 10600 work_mem = 102400 enable_seqscan = false
still no improvement
Ok here's the Plan with the enable_seqscan = false: ausclimate=# explain ANALYZE select count(*) from "getfutureausclimate";
Actually, you probably don't want enable_seqscan=off, you should try: SET enable_nestloop TO off. The problem is that it is estimating there will only be 44 rows, but in reality there are 13M rows. It almost definitely should be doing a seqscan with a sort and merge join.
Also, please attach you explain analyzes, the wrapping is really hard to read.
I don't understand how postgres could get the number of rows that wrong.
It seems to be misestimating the number of entries in IX_ClimateId
-> Index Scan using "PK_Aus40_DEM" on "Aus40_DEM" (cost=0.00..6.01 rows=1 width=16) (actual time=0.005..0.006 rows=1 loops=13276368) Index Cond: ("outer"."AusPosNumber" = "Aus40_DEM"."AusPosNumber") -> Index Scan using "PK_CurrentAusClimate" on "CurrentAusClimate" (cost=0.00..46.20 rows=11 width=14) (actual time=0.007..0.009 rows=1 loops=13276368)
The first index scan is costing you 0.006*13276368=79s, and the second one is 119s.
I can't figure out exactly what is where from the formatting, but the query that seems misestimated is: -> Index Scan using "IX_ClimateId" on "ClimateChangeModel40" (cost=0.00..1063711.75 rows=265528 width=20) (actual time=28.311..17212.703 rows=13276368 loops=1) Index Cond: ("outer"."ClimateId" = "ClimateChangeModel40"."ClimateId")
Is there an unexpected correlaction between ClimateChangeModel40"."ClimateId" and whatever "outer" is at this point?
Description: OpenPGP digital signature