Re: Auto Vacuum Daemon (again...)

----- Original Message -----
From: "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in>
To: "Matthew T. O'Connor" <matthew(at)zeut(dot)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