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
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
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.
> > >
> >
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 imagine larger systems with multiple CPUs and m
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
> > 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 datab
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 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
- 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&
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 run
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 al
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
"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 c
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 wo
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 back
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)
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 rather
17 matches
Mail list logo
