On Fri, 2002-11-29 at 07:19, Shridhar Daithankar wrote:
On 29 Nov 2002 at 7:59, Matthew T. O'Connor wrote:
On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote:
On 28 Nov 2002 at 10:45, Tom Lane wrote:
This is almost certainly a bad idea. vacuum is not very
On 10 Dec 2002 at 9:42, Rod Taylor wrote:
Perhaps a more appropriate rule would be 1 AVD per tablespace? Since
PostgreSQL only has a single tablespace at the moment
Sorry I am talking without doing much of it(Stuck to windows for job) But
actually when I was talking with Matthew offlist,
On Fri, 2002-11-29 at 06:59, Matthew T. O'Connor wrote:
On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote:
On 28 Nov 2002 at 10:45, Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
interesting thought. I think this boils down to how many knobs do we
need to
Not sure what you mean by that, but it sounds like the behaviour of my AVD
(having it block until the vacuum command completes) is fine, and perhaps
preferrable.
I can easily imagine larger systems with multiple CPUs and multiple disk
and card bundles to support multiple databases.
On Tue, 2002-12-10 at 12:00, Greg Copeland wrote:
On Tue, 2002-12-10 at 08:42, Rod Taylor wrote:
Not sure what you mean by that, but it sounds like the behaviour of my AVD
(having it block until the vacuum command completes) is fine, and perhaps
preferrable.
I can easily
On 10 Dec 2002, Rod Taylor wrote:
Not sure what you mean by that, but it sounds like the behaviour of my AVD
(having it block until the vacuum command completes) is fine, and perhaps
preferrable.
I can easily imagine larger systems with multiple CPUs and multiple disk
and card
On Tue, 2002-12-10 at 13:09, scott.marlowe wrote:
On 10 Dec 2002, Rod Taylor wrote:
Perhaps a more appropriate rule would be 1 AVD per tablespace? Since
PostgreSQL only has a single tablespace at the moment
But Postgresql can already place different databases on different data
- Original Message -
From: Shridhar Daithankar [EMAIL PROTECTED]
To: Matthew T. O'Connor [EMAIL PROTECTED]
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
On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote:
On 28 Nov 2002 at 10:45, Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
interesting thought. I think this boils down to how many knobs do we
need to put on this system. It might make sense to say allow upto X
On 29 Nov 2002 at 7:59, Matthew T. O'Connor wrote:
On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote:
On 28 Nov 2002 at 10:45, Tom Lane wrote:
This is almost certainly a bad idea. vacuum is not very
processor-intensive, but it is disk-intensive. Multiple vacuums running
On Thu, 2002-11-28 at 01:58, Shridhar Daithankar wrote:
There are differences in approach here. The reason I prefer polling rather than
signalig is IMO vacuum should always be a low priority activity and as such it
does not deserve a signalling overhead.
A simpler way of integrating would
Matthew T. O'Connor [EMAIL PROTECTED] writes:
interesting thought. I think this boils down to how many knobs do we
need to put on this system. It might make sense to say allow upto X
concurrent vacuums, a 4 processor system might handle 4 concurrent
vacuums very well.
This is almost
On 28 Nov 2002 at 10:45, Tom Lane wrote:
Matthew T. O'Connor [EMAIL PROTECTED] writes:
interesting thought. I think this boils down to how many knobs do we
need to put on this system. It might make sense to say allow upto X
concurrent vacuums, a 4 processor system might handle 4
On 27 Nov 2002 at 13:01, Matthew T. O'Connor wrote:
On Wed, 2002-11-27 at 01:59, Shridhar Daithankar wrote:
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,
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
Several months ago tried to implement a special postgres backend as an
Auto Vacuum Daemon (AVD), somewhat like the stats collector. I failed
due to my lack of experience with the postgres source.
On Sep 23, Shridhar Daithankar released an AVD written in C++ that acted
as a client program
16 matches
Mail list logo
