Searching the archives, I found a couple of 2006 posts that seem somewhat related to my problem (although I don't see any solutions listed...): http://archives.postgresql.org/pgsql-hackers/2006-09/msg00415.php http://archives.postgresql.org/pgsql-hackers/2006-04/msg00127.php Tom, since you were involved in these - did you ever figure out how to resolve the issues of the stats collector getting stuck in Windows? Thanks, Jeremy Haile On Wed, 24 Jan 2007 14:19:05 -0500, "Jeremy Haile" <jhaile@xxxxxxxxxxx> said: > pgstat.stat was last updated 1/22 12:25pm - there is no pgstat.tmp. > > Coincidentally (I think not) - the last auto-analyze was performed at > 2007-01-22 12:24:11.424-05. > > The logs for 1/22 are empty - so no errors or anything like that to give > clues... > > Thanks! > Jeremy Haile > > > On Wed, 24 Jan 2007 14:00:52 -0500, "Tom Lane" <tgl@xxxxxxxxxxxxx> said: > > "Jeremy Haile" <jhaile@xxxxxxxxxxx> writes: > > > The stats collector appears to still be running, since I can see a > > > postgres.exe process with -forkcol. However, I never notice it using > > > I/O or CPU usage. Also, querying the pg_stat_user_tables view shows no > > > change in table stats even for tables that change very frequently. > > > > Is $PGDATA/global/pgstat.stat getting updated? (watch the file mod time > > at least) Do you see any pgstat.tmp file in there? > > > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match
