Re: Auto Vacuum Daemon (again...) - Mailing list pgsql-hackers
From | Matthew T. O'Connor |
---|---|
Subject | Re: Auto Vacuum Daemon (again...) |
Date | |
Msg-id | 002101c29a55$baf10310$6d00a8c0@sales4 Whole thread Raw |
In response to | Re: Auto Vacuum Daemon (again...) ("Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>) |
List | pgsql-hackers |
----- Original Message ----- From: "Shridhar Daithankar" <shridhar_daithankar@persistent.co.in> To: "Matthew T. O'Connor" <matthew@zeut.net> Sent: Monday, December 02, 2002 11:12 AM Subject: Re: [HACKERS] Auto Vacuum Daemon (again...) > On 28 Nov 2002 at 3:02, Matthew T. O'Connor wrote: > I went thr. it today and I have some comments to make. > > 1. The idea of using single database is real great. I really liked that > idea which keeps configuration simple. I'm no longer think this is a good idea. Tom Lane responded to our thread on the hacker list saying that it would never be a good idea to have more than one vacuum process running at a time, even on different databases as vacuum is typically io bound. Since never want to run more than one vacuum at a time, it is much simpler to have it all managed by one AVD, rather than one AVD for each database on a server. > 2. You are fetching all the statistics in the list. This could get big if > there are thousands of table or for a hosting companies where there are tons > of databases. That is the reason I put a table in there.. > > Of course not that it won't work, but by putting a table I thought it > cause some less code in the app. I don't see how putting a table in is any different than checking the view. First I don't like the idea of having to have tables in someones database, I find that intrusive. I know that some packages such as PGAdmin do this, and I never liked it as a developer. Second, the only reason that it would be less work for the server is that you may not have an entry in your table for all tables in the database. This can be accomplished through some type of exclusion list that could be part of the configuration system. > I will hack in a add-on for parallel vacuums by tom. and send you. Just > put a command line switch(never played with getopt). Basically,after list of > database is read, fork a child that sleeps and vacuums only one database. See comments above. > Besides I have couple of bugreports which I will check against your > version as well.. Please let me know what you find, I know it's far from a polished piece of work yet :-) > After a thorough look of code, I will come up with more of these but next > time I will send you patched rather than comments.. I look forward to it. Also, I wanted to let you know that I am working on integrating it into the main Postgres source tree right now. From what I have heard on the hackers list it seems that they are hoping to have this be a core feature that they can depend on so that they can guarantee that databases are vacuumed every so often as required for 24x7 operation. Basically I will still have it as a separate executable, but the postmaster will take care of launching it with proper arguments, restarting it if it dies (much like the stats collector) and stop the AVD on shutdown. This should be fairly easy to do, I still don't know if others think this is a good idea, as I got to response to that part of my other email, but it is the best idea I have right now. > Sorry for late reply. Still fighting with some *very* stupid bugs in my > daytime jobs ( like 'if (k < 60)' evaluating to false for k=0 in release version > only etc..) Good luck with your work, I hope you find all the bugs quickly, Its not the fun part of coding. Thanks again for the feedback, I really want this feature in postgres. Matthew
pgsql-hackers by date: