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)  (Gavin Sherry <swm@alcove.com.au>)
Re: two queries and dual cpu (perplexed)  (Jeff <threshar@torgo.978.org>)
Список 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 по дате отправления:

Предыдущее
От: Enrico Weigelt
Дата:
Сообщение: foreign key performance
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: foreign key performance