Simon Riggs wrote: > Galy, please hear that people like your idea and understand your use > case, but just don't like all of the proposal, just the main thrust of > it. The usual way is that > (people that agree + amount of your exact idea remaining) = 100%
Thank you. I am glad to hear that. :) But I still can not kill my idea yet. Let's come to the core issue we care about: do we need the stop-on-dime feature to stop vacuum immediately? As my previous opinion: if there are some problems for long running vacuum, yes we *did need* to stop vacuum immediately. I am still not convinced that we don’t have such kind of problems. The potential problem for running a long vacuum is that it may block some foreground transactions, like ALTER TABLE; if it is true that long running vacuum did block some DDLs for a long time, it is a big problem. I think we need to stop vacuum immediately to handle such kind of problems. I admit that the implementation is much complex, but I can not see any big problems to save the dead tuples out and read it in again(like two phase commit does). Why do we need to hold the lock and transaction? We can open the lock and abandon the transaction ID, vacuum can take the lock and get a new ID when restarting. Why do we need to worry about if the dead tuple is still alive, only vacuum will sweep them, HOT can not touch the tuple until we have finished sweeping. But it is true that in some scenarios, it is better to stop after the cycle has finished, then the effect of vacuum can appear quickly. So I hope the final design may combine then together. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend