Jan Wieck wrote: > Bruce Momjian wrote: > > > Jan Wieck wrote: > >> Attached is a corrected version that solves the query cancel problem by > >> not napping any more and going full speed as soon as any signal is > >> pending. If nobody objects, I'm going to commit this tomorrow. > > > > Jan, three questions. First, is this useful now that we have the new > > cache replacement code, second, do we need this many parameters (can't > > any of them be autotuned), and third, what about documentation? > > > > You mean if stopping to nap is useful when a signal is pending or if > napping during vacuum itself is useful at all? > > I am willing to make it all self tuning and automagic. Just tell me how.
I was hoping you would have some ideas. :-) I guess my question is that now that we have the new cache replacement policy, is the vacuum delay worth while. I looked at http://developer.postgresql.org/~wieck/vacuum_cost/ and does seem useful. > Documentation is missing so far. Will work on that. Cool. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(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