On Fri, Oct 17, 2014 at 1:31 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > > On 16 October 2014 15:09, Amit Kapila <amit.kapil...@gmail.com> wrote: > > > I think doing anything on the server side can have higher complexity like: > > a. Does this function return immediately after sending request to > > autovacuum, if yes then the behaviour of this new functionality > > will be different as compare to vacuumdb which user might not > > expect? > > b. We need to have some way to handle errors that can occur in > > autovacuum (may be need to find a way to pass back to user), > > vacuumdb or Vacuum can report error to user. > > c. How does nworkers input relates to autovacuum_max_workers > > which is needed at start for shared memory initialization and in calc > > of maxbackends. > > d. How to handle database wide vacuum which is possible via vacuumdb > > e. What is the best UI (a command like above or via config parameters)? > > > c) seems like the only issue that needs any thought. I don't think its > going to be that hard. > > I don't see any problems with the other points. You can make a > function wait, if you wish.
It is quite possible, but still I think to accomplish such a function, we need to have some mechanism where it can inform auto vacuum and then some changes in auto vacuum to receive/read that information and reply back. I don't think any such mechanism exists. > > I think we can find a way for above and may be if any other similar things > > needs to be taken care, but still I think it is better that we have this > > feature > > via vacuumdb rather than adding complexity in server code. Also the > > current algorithm used in patch is discussed and agreed upon in this > > thread and if now we want to go via some other method (auto vacuum), > > it might take much more time to build consensus on all the points. > > Well, I read Alvaro's point from earlier in the thread and agreed with > it. All we really need is an instruction to autovacuum to say "be > aggressive". > > Just because somebody added something to the TODO list doesn't make it > a good idea. I apologise to Dilip for saying this, it is not anything > against him, just the idea. > > Perhaps we just accept the patch and change AV in the future. So shall we move ahead with review of this patch and make a note of changing AV in future (may be TODO)? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
