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
Here:
-> 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?
John
=:->
signature.asc
Description: OpenPGP digital signature
