Re: Auto Vacuum Daemon (again...)

On 26 Nov 2002 at 21:54, Matthew T. O'Connor wrote:
> First: Do we want AVD integrated into the main source tree, or should it
> remain a "tool" that can be downloaded from gborg. I would think it
> should be controlled by the postmaster, and configured from GUC (at
> least basic on off settings)

Since you have rewritten in C, I think it can be safely added to contrib, after 
core team agrees. It is a good place for such things.

> Second: Assuming we want it integrated into the source tree, can it
> remain a client app?  Can a non backend program that connects to the
> postmaster using libpq be a child of the postmaster that the postmaster
> can control (start and stop).

I would not like postmaster forking into pgavd app. As far as possible, we 
should not touch the core. This is a client app. and be it that way. Once we 
integrate it into backend, we need to test the integration as well. Why bother?

> Anyway for you reading pleasure, I have attached a plot of results from
> a simple test program I wrote. As you can see from the plot, AVD keeps
> the file size under control.  Also, the first few Xacts are faster in
> the non AVD case, but after that AVD keeps the average Xact time down. 
> The periodic spikes in the AVD run correspond to when the AVD has fired
> off a vacuum.  Also when the table file gets to approx 450MB performance
> drops off horribly I assume this is because my system can no longer
> cache the whole file (I have 512M in my machine).  Also, I had been
> developing against 7.2.3 until recently, and I wound up doing some of
> these benchmarks against both 7.2.3 and 7.3devel and 7.3 perfoms much
> better, that is it 7.2 slowed down much sooner under this test.

Good to know that it works.

I would like to comment w.r.t to my original effort.

1) I intentionally left vacuum full to admin. Disk space is cheap and we all 
know that but IMO no application should lock a table without admin knowing it. 
This is kinda microsoftish assumption of user friendliness to make decision on 
behalf of users. Of course, sending admin a notigication is a good idea..

2)In a cluster if there are many databases and time taken for serial vacuum is 
more than time gap between two wake-up intervals of AVD, it would get into a 
continous vacuum. At some point of time, we are going to need one connection 
per database in separate process/thread.

Thanks for your work..

ByeShridhar

--
Distinctive, adj.:    A different color or shape than our competitors.