Re: two queries and dual cpu (perplexed)
От | Shoaib Burq (VPAC) |
---|---|
Тема | Re: two queries and dual cpu (perplexed) |
Дата | |
Msg-id | Pine.LNX.4.44.0504221328410.14851-200000@hp.vpac.org обсуждение исходный текст |
Ответ на | Re: two queries and dual cpu (perplexed) (John A Meinel <john@arbash-meinel.com>) |
Ответы |
Re: two queries and dual cpu (perplexed)
Re: two queries and dual cpu (perplexed) |
Список | pgsql-performance |
Please see attached the output from explain analyse. This is with the shared_buffers = 10600 work_mem = 102400 enable_seqscan = true BTW I guess should mention that I am doing the select count(*) on a View. Ran the Explain analyse with the nestedloop disabled but it was taking forever... and killed it after 30mins. Thanks shoaib On Thu, 21 Apr 2005, John A Meinel wrote: > 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=1loops=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.009rows=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.703rows=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 > =:-> > >
Вложения
В списке pgsql-performance по дате отправления: