Re: two queries and dual cpu (perplexed)

От: Tom Lane
Тема: Re: two queries and dual cpu (perplexed)
Дата: ,
Msg-id: 24112.1114301405@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: two queries and dual cpu (perplexed)  (John A Meinel)
Ответы: Re: two queries and dual cpu (perplexed)  ("Shoaib Burq (VPAC)")
Список: pgsql-performance

Скрыть дерево обсуждения

two queries and dual cpu (perplexed)  ("Shoaib Burq (VPAC)", )
 Re: two queries and dual cpu (perplexed)  (Jeff, )
  Re: two queries and dual cpu (perplexed)  (Gavin Sherry, )
  Re: two queries and dual cpu (perplexed)  ("Shoaib Burq (VPAC)", )
   Re: two queries and dual cpu (perplexed)  (Russell Smith, )
    Re: two queries and dual cpu (perplexed)  ("Shoaib Burq (VPAC)", )
     Re: two queries and dual cpu (perplexed)  (John A Meinel, )
      Re: two queries and dual cpu (perplexed)  ("Shoaib Burq (VPAC)", )
       Re: two queries and dual cpu (perplexed)  (Gavin Sherry, )
       Re: two queries and dual cpu (perplexed)  (Jeff, )
      Re: two queries and dual cpu (perplexed)  (Tom Lane, )
       Re: two queries and dual cpu (perplexed)  ("Shoaib Burq (VPAC)", )
        Re: two queries and dual cpu (perplexed)  (John A Meinel, )
   Re: two queries and dual cpu (perplexed)  ("Shoaib Burq (VPAC)", )
  Re: two queries and dual cpu (perplexed)  ("Shoaib Burq (VPAC)", )
  Re: two queries and dual cpu (perplexed)  (Kenneth Marshall, )
 Re: two queries and dual cpu (perplexed)  (Daniel Schuchardt, )
 Re: two queries and dual cpu (perplexed)  ("Dave Held", )

John A Meinel <> writes:
> 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.

Not nestloops anyway.

> I don't understand how postgres could get the number of rows that wrong.

No stats, or out-of-date stats is the most likely bet.

> 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")

Yeah, that's what jumped out at me too.  It's not the full explanation
for the join number being so far off, but this one at least you have a
chance to fix by updating the stats on ClimateChangeModel40.

            regards, tom lane


В списке pgsql-performance по дате сообщения:

От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Bad n_distinct estimation; hacks suggested?
От: Marko Ristola
Дата:
Сообщение: Re: [ODBC] Joel's Performance Issues WAS : Opteron vs Xeon