Re: Bad choice of query plan from PG 7.3.6 to PG 7.3.9

Wouldn't the VACUUM have made them equivalent??

anyway, here's the info for relpages:
Live Server: 424
Test Server: 338

Please note though that there're more rows on the live server than on
the test server due to recent upload.
Total Row counts are as follows:
Live Server: 12597
Test Server: 11494

When the problems started the tables had identical size though.

Cheers
Jona

Tom Lane wrote:

>Jona <jonanews(at)oismail(dot)com> writes:
>
>
>>Test Server:
>>comm=# VACUUM ANALYZE VERBOSE StatCon_Tbl;
>>INFO: --Relation public.statcon_tbl--
>>INFO: Pages 338: Changed 0, Empty 0; Tup 11494: Vac 0, Keep 0, UnUsed 0.
>> Total CPU 0.02s/0.00u sec elapsed 1.98 sec.
>>INFO: --Relation pg_toast.pg_toast_179851--
>>INFO: Pages 85680: Changed 0, Empty 0; Tup 343321: Vac 0, Keep 0, UnUsed 0.
>> Total CPU 1.75s/0.23u sec elapsed 30.36 sec.
>>INFO: Analyzing public.statcon_tbl
>>VACUUM
>>
>>
>
>
>
>>Live Server:
>>comm=# VACUUM ANALYZE VERBOSE StatCon_Tbl;
>>INFO: --Relation public.statcon_tbl--
>>INFO: Pages 424: Changed 0, Empty 0; Tup 12291: Vac 0, Keep 0, UnUsed 6101.
>> Total CPU 0.00s/0.01u sec elapsed 0.01 sec.
>>INFO: --Relation pg_toast.pg_toast_891830--
>>INFO: Pages 89234: Changed 0, Empty 0; Tup 352823: Vac 0, Keep 0,
>>UnUsed 5487.
>> Total CPU 3.21s/0.47u sec elapsed 18.03 sec.
>>INFO: Analyzing public.statcon_tbl
>>VACUUM
>>
>>
>
>Hm, the physical table sizes aren't very different, which suggests that
>the problem must lie with the indexes. Unfortunately, VACUUM in 7.3
>doesn't tell you anything about indexes if it doesn't have any dead rows
>to clean up. Could you look at pg_class.relpages for all the indexes
>of this table, and see what that shows?
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>