Received: from localhost (maia-1.hub.org [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id 6A7D99FA4C1
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Wed,  3 Jan 2007 11:31:40 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024)
	with ESMTP id 34451-07 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Wed,  3 Jan 2007 11:31:33 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id C48119FA4BC
	for <pgsql-performance@postgresql.org>;
	Wed,  3 Jan 2007 11:31:33 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id l03FVW9T005139;
	Wed, 3 Jan 2007 10:31:32 -0500 (EST)
To: =?iso-8859-1?q?Rolf=20=D8stvik?= <rolfostvik@yahoo.no>
cc: pgsql-performance@postgresql.org
Subject: Re: Worse perfomance on 8.2.0 than on 7.4.14 
In-reply-to: <22580.68259.qm@web26303.mail.ukl.yahoo.com> 
References: <22580.68259.qm@web26303.mail.ukl.yahoo.com>
Comments: In-reply-to =?iso-8859-1?q?Rolf=20=D8stvik?= <rolfostvik@yahoo.no>
	message dated "Wed, 03 Jan 2007 09:01:37 +0100"
Date: Wed, 03 Jan 2007 10:31:32 -0500
Message-ID: <5138.1167838292@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200701/32
X-Sequence-Number: 22633

=?iso-8859-1?q?Rolf=20=D8stvik?= <rolfostvik@yahoo.no> writes:
>  Index Scan using step_result_uut_result_idx on step_result_subset  (cost=0.00..563.85 rows=23
> width=4) (actual time=0.069..0.069 rows=0 loops=1)
>    Index Cond: (uut_result = $1)
>    Filter: (step_parent = 0)
>  Total runtime: 0.112 ms
> (4 rows)

Hm, that's interesting.  In your original message we have the following
for 7.4's estimate of the same plan step:

   ->  Index Scan using step_result_uut_result_idx on step_result_subset sr  (cost=0.00..74.28 rows=2 width=8) (actual time=0.149..0.379 rows=1 loops=68)
         Index Cond: ("outer".id = sr.uut_result)
         Filter: (step_parent = 0)

The number-of-matching-rows estimate has gone up by a factor of 10,
which undoubtedly has a lot to do with the much higher cost estimate.
Do you have any idea why that is ... is the table really the same size
in both servers?  If so, could we see the pg_stats row for
step_result_subset.uut_result on both servers?

			regards, tom lane