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 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?
In response to
pgsql-performance by date
|Next:||From: Richard van den Berg||Date: 2005-04-21 15:54:33|
|Subject: Re: When are index scans used over seq scans?|
|Previous:||From: Shoaib Burq (VPAC)||Date: 2005-04-21 15:01:19|
|Subject: Re: two queries and dual cpu (perplexed)|