Re: Query Plan far worse in 7.3.2 than 7.2.1 - Mailing list pgsql-performance

From SZŰCS Gábor
Subject Re: Query Plan far worse in 7.3.2 than 7.2.1
Date
Msg-id 004401c30f07$c07f45e0$0a03a8c0@fejleszt2
Whole thread Raw
In response to Query Plan far worse in 7.3.2 than 7.2.1  ("SZŰCS Gábor" <surrano@mailbox.hu>)
List pgsql-performance
----- Original Message -----
From: "Tom Lane" <tgl@sss.pgh.pa.us>
Sent: Wednesday, April 30, 2003 1:05 AM


> "=?iso-8859-2?B?U1rbQ1MgR+Fib3I=?=" <surrano@mailbox.hu> writes:
> > ---------------------------- 7.2.1
PLAN ---------------------------------
> >     ->  Seq Scan on valuta  (cost=0.00..1.06 rows=6 width=4) (actual
time=0.02..0.11 rows=6 loops=2)
> >
> > ---------------------------- 7.3.2
PLAN ---------------------------------
> >                                        ->  Seq Scan on valuta
(cost=0.00..20.00 rows=1000 width=4) (actual time=0.02..0.06 rows=6 loops=2)
>
> Ah, there's the problem.  You never vacuumed or analyzed "valuta", so
> the 7.3 planner didn't know it had only six rows, and chose a plan that
> was more appropriate for a larger table.  The thousand-row estimate is
> the tipoff, because that's the default assumption when there are no
> stats.
>
> regards, tom lane

Thanks!

VACUUM ANALYZE really worked and I learned something new.

The strange part is, that I think I issued a "VACUUM ANALYZE;" (that should
do all the tables, right?) a couple of weeks before because of another
problem (it didn't help that time, tho)

G.
--
while (!asleep()) sheep++;

---------------------------- cut here ------------------------------


pgsql-performance by date:

Previous
From: Rajesh Kumar Mallah
Date:
Subject: Re: Is 292 inserts/sec acceptable performance ?
Next
From: Manfred Koizar
Date:
Subject: Re: More tablescanning fun