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

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