Skip site navigation (1) Skip section navigation (2)

Re: two queries and dual cpu (perplexed)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John A Meinel <john(at)arbash-meinel(dot)com>
Cc: "Shoaib Burq (VPAC)" <sab(at)vpac(dot)org>,Russell Smith <mr-russ(at)pws(dot)com(dot)au>, Jeff <threshar(at)torgo(dot)978(dot)org>,pgsql-performance(at)postgresql(dot)org
Subject: Re: two queries and dual cpu (perplexed)
Date: 2005-04-24 00:10:05
Message-ID: 24112.1114301405@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-performance
John A Meinel <john(at)arbash-meinel(dot)com> 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.703 rows=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

In response to

Responses

pgsql-performance by date

Next:From: Thomas F.O'ConnellDate: 2005-04-24 02:31:13
Subject: Re: pgbench Comparison of 7.4.7 to 8.0.2
Previous:From: Josh BerkusDate: 2005-04-23 23:53:16
Subject: Re: Bad n_distinct estimation; hacks suggested?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group