Sorry Tom, misread your mail! My bad :-(
I believe the following is the data you need ?
Live Server
relname
relpages
ctp_statcon
72
statcon_pk
135
Test Server
Jona <[EMAIL PROTECTED]> writes:
> anyway, here's the info for relpages:
> Live Server: 424
> Test Server: 338
I was asking about the indexes associated with the table, not the table
itself.
regards, tom lane
---(end of broadcast)--
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:
Jona <[EMAIL PROTECTED]> 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_toa
Now with analyze
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 8568
You didn't do analyze.
Chris
Jona wrote:
Results of VACUUM VERBOSE from both servers
Test server:
comm=# VACUUM VERBOSE StatCon_Tbl;
INFO: --Relation public.statcon_tbl--
INFO: Pages 338: Changed 338, Empty 0; Tup 11494: Vac 0, Keep 0, UnUsed 0.
Total CPU 0.02s/0.00u sec elapsed 0.04 se
Results of VACUUM VERBOSE from both servers
Test server:
comm=# VACUUM VERBOSE StatCon_Tbl;
INFO: --Relation public.statcon_tbl--
INFO: Pages 338: Changed 338, Empty 0; Tup 11494: Vac 0, Keep 0,
UnUsed 0.
Total CPU 0.02s/0.00u sec elapsed 0.04 sec.
INFO: --Relation pg_toast.pg_toast
Thank you for the swift reply.
The test server is hardly ever vacuumed as it in general sees very
limited traffic. vacuum is only necessary if the server sees a lot of
write operations, i.e. update, delete, insert right?
What explains the different choice of query plans then?
As can be seen fr
Jona <[EMAIL PROTECTED]> writes:
> I'm currently experiencing problems with long query execution times.
> What I believe makes these problems particularly interesting is the
> difference in execution plans between our test server running PostGreSQL
> 7.3.6 and our production server running PostGr
