Re: Worse perfomance on 8.2.0 than on 7.4.14 - Mailing list pgsql-performance

From Tom Lane
Subject Re: Worse perfomance on 8.2.0 than on 7.4.14
Date
Msg-id 5138.1167838292@sss.pgh.pa.us
Whole thread Raw
In response to Re: Worse perfomance on 8.2.0 than on 7.4.14  (Rolf Østvik <rolfostvik@yahoo.no>)
Responses Re: Worse perfomance on 8.2.0 than on 7.4.14  (Rolf Østvik <rolfostvik@yahoo.no>)
List pgsql-performance
=?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.379rows=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

pgsql-performance by date:

Previous
From: Rolf Østvik
Date:
Subject: Re: Worse perfomance on 8.2.0 than on 7.4.14
Next
From: Erik Jones
Date:
Subject: Re: More 8.2 client issues (Was: [Slow dump?)