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

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 

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?


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to