Gaetano Mendola wrote:
Vivek Khera wrote:
"MTO" == Matthew T O'Connor <[EMAIL PROTECTED]> writes:
Then it just sits there. I started it at 11:35am, and it is now
3:30pm.
MTO> Weird.... Alphabetically speaking, is vkmlm."public"."user_list"
be the
MTO> last table in the last schema in the last database? You are running
conveniently, yes it is...
MTO> with -d4, so you would get a message about going to sleep shortly
after
MTO> dealing with the last table, but you didn't get the sleep
message, so I
MTO> don't think the problem is that pg_autovacuum is sleeping for an
MTO> inordinate amount time.
The only sleep logged was
[2003-12-03 04:47:13 PM] 1 All DBs checked in: 84996853 usec, will
sleep for 469 secs.
What I seen is:
# tail -f auto.log
[2003-12-04 07:10:18 PM] reltuples: 72; relpages: 1
[2003-12-04 07:10:18 PM] curr_analyze_count: 72; cur_delete_count: 0
[2003-12-04 07:10:18 PM] ins_at_last_analyze: 72; del_at_last_vacuum: 0
[2003-12-04 07:10:18 PM] insert_threshold: 572; delete_threshold 536
[2003-12-04 07:10:18 PM] table name: empdb."public"."contracts"
[2003-12-04 07:10:18 PM] relfilenode: 17784; relisshared: 0
[2003-12-04 07:10:18 PM] reltuples: 347; relpages: 5
[2003-12-04 07:10:18 PM] curr_analyze_count: 347; cur_delete_count: 0
[2003-12-04 07:10:18 PM] ins_at_last_analyze: 347; del_at_last_vacuum: 0
[2003-12-04 07:10:18 PM] insert_threshold: 847; delete_threshold 673
[ 5 minutes of delay ] <----- LOOK THIS
[2003-12-04 07:10:18 PM] 503 All DBs checked in: 179396 usec, will sleep
for 300 secs.
[2003-12-04 07:15:19 PM] 504 All DBs checked in: 98814 usec, will sleep
for 300 secs.
I think is a good Idea put a fflush after:
fprintf(LOGOUTPUT, "[%s] %s\n", timebuffer, logentry);
Was I wrong ? If you are watching in tail the log believeme is really
annoying.
Regards
Gaetano Mendola
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
