On Tue, 5 Aug 2003, Shridhar Daithankar wrote:
> On 5 Aug 2003 at 14:15, Peter Childs wrote:
>
> > On Tue, 5 Aug 2003, Shridhar Daithankar wrote:
> >
> > > On 5 Aug 2003 at 8:09, Jeff wrote:
> > >
> > > I would suggest autovacuum daemon which is in CVS contrib works for 7.3.x as
> > > well..
On Wed, Aug 06, 2003 at 12:45:34AM -0400, Tom Lane wrote:
> For core code, the answer would be a big NYET. We do not do feature
> additions in point releases, only bug fixes. While contrib code is more
> under the author's control than the core committee's control, I'd still
> say that you'd be m
> On Tue, 2003-08-05 at 17:40, Christopher Browne wrote:
> > Unfortunately, a "configurable-via-tables" pg_autovacuum is also going
> > to be quite different from the current "unconfigurable" version.
You don't need to create actual tables - just use 'virtual' tables, like the
pg_settings one. T
Matthew T. O'Connor wrote:
> Fair point, my only concern is that a backend integrated
> pg_autovacuum would be radically different from the current libpq
> based client application.
Unfortunately, a "configurable-via-tables" pg_autovacuum is also going
to be quite different from the current "uncon
Try the pg_autovacuum daemon in CVS contrib dir. It works fine with 7.3.
Chris
- Original Message -
From: "Jeff" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 05, 2003 8:09 PM
Subject: [PERFORM] Some vacuum & tuning help
> I've
From: "Christopher Browne" <[EMAIL PROTECTED]>
> Shridhar Daithankar wrote:
> > I agree, specifying per table thresholds would be good in autovacuum..
>
> Which begs the question of what the future direction is for pg_autovacuum.
This is a good question.
> There would be some merit to having pg_
I've been trying to search through the archives, but it hasn't been
successful.
We recently upgraded from pg7.0.2 to 7.3.4 and things were happy. I'm
trying to fine tune things to get it running a bit better and I'm trying
to figure out how vacuum output correlates to tuning parameters.
Here's th
On 5 Aug 2003 at 9:18, Jeff wrote:
> As for the pg_dumping of it. I suppose it would work on this table as it
> is only a couple million rows and not terribly big data-wise. The other
> tables in this db are rather big and a load is not fast. (It is about
> 8GB).
You need to dump only those table
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> ... My really question
> was can I make large changes to a contrib module to a point release,
> meaning, 7.4.0 will have what is in beta, but 7.4.1 would have a much
> improved version. Does that sound possible?
For core code, the answer would b
On Tue, 2003-08-05 at 12:49, Bruce Momjian wrote:
> > Well, the bar is lower for contrib stuff than for core, but you'd better
> > get such changes in PDQ, I'd say ...
>
> The contrib stuff is usually at the control of the author, so you can
> make changes relatively late. However, the later the
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Since pg_autovaccum is a contrib module does that mean I can make functional
> changes that will be included in point release of 7.4?
Well, the bar is lower for contrib stuff than for core, but you'd better
get such changes in PDQ, I'd say ...
On Wed, 2003-08-06 at 00:45, Tom Lane wrote:
> For core code, the answer would be a big NYET. We do not do feature
> additions in point releases, only bug fixes. While contrib code is more
> under the author's control than the core committee's control, I'd still
> say that you'd be making a big m
On 5 Aug 2003 at 14:15, Peter Childs wrote:
> On Tue, 5 Aug 2003, Shridhar Daithankar wrote:
>
> > On 5 Aug 2003 at 8:09, Jeff wrote:
> >
> > I would suggest autovacuum daemon which is in CVS contrib works for 7.3.x as
> > well.. Or schedule a vacuum analyze every 15 minutes or so..
>
>
On 5 Aug 2003 at 10:29, Christopher Browne wrote:
> Shridhar Daithankar wrote:
> > I agree, specifying per table thresholds would be good in autovacuum..
>
> Which begs the question of what the future direction is for pg_autovacuum.
>
> There would be some merit to having pg_autovacuum throw
Matthew T. O'Connor wrote:
> On Tue, 2003-08-05 at 12:49, Bruce Momjian wrote:
> > > Well, the bar is lower for contrib stuff than for core, but you'd better
> > > get such changes in PDQ, I'd say ...
> >
> > The contrib stuff is usually at the control of the author, so you can
> > make changes re
From: "Tom Lane" <[EMAIL PROTECTED]>
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> So, now is precisely the time to be experimenting to find out what works
well and what features are needed.
Another quick question while I have your attention :-)
Since pg_autovaccum is a contrib module doe
From: "Tom Lane" <[EMAIL PROTECTED]>
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > I chose to leave pg_autovacuum simple and not add too many features
because
> > the core team has said that it needs to be integrated into the backend
> > before it can be considered a core tool.
>
> I thin
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> I chose to leave pg_autovacuum simple and not add too many features because
> the core team has said that it needs to be integrated into the backend
> before it can be considered a core tool.
I think actually it makes plenty of sense to enhance p
On 5 Aug 2003 at 8:09, Jeff wrote:
> I've been trying to search through the archives, but it hasn't been
> successful.
>
> We recently upgraded from pg7.0.2 to 7.3.4 and things were happy. I'm
> trying to fine tune things to get it running a bit better and I'm trying
> to figure out how vacuum ou
Shridhar Daithankar wrote:
> I agree, specifying per table thresholds would be good in autovacuum..
Which begs the question of what the future direction is for pg_autovacuum.
There would be some merit to having pg_autovacuum throw in some tables
in which to store persistent information, and at
On Tue, 5 Aug 2003, Shridhar Daithankar wrote:
> On 5 Aug 2003 at 8:09, Jeff wrote:
>
> I would suggest autovacuum daemon which is in CVS contrib works for 7.3.x as
> well.. Or schedule a vacuum analyze every 15 minutes or so..
I've just got autovacum up and Since we have had a lot of
Jeff <[EMAIL PROTECTED]> writes:
> Here's the msot recent vacuum for the "active" table. It gets a few
> hundred updates/inserts a minute constantly throughout the day.
> INFO: Pages 27781: Changed 0, Empty 0; Tup 2451648: Vac 0, Keep 0, UnUsed
> 1003361.
> Total CPU 2.18s/0.61u sec elap
On Tue, 2003-08-05 at 17:40, Christopher Browne wrote:
> Unfortunately, a "configurable-via-tables" pg_autovacuum is also going
> to be quite different from the current "unconfigurable" version.
true, however I would like to preserve the "unconfigured" functionality
so that it can be run against a
Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > Since pg_autovaccum is a contrib module does that mean I can make functional
> > changes that will be included in point release of 7.4?
>
> Well, the bar is lower for contrib stuff than for core, but you'd better
> get such ch
On Tue, 5 Aug 2003, Shridhar Daithankar wrote:
>
> I would suggest autovacuum daemon which is in CVS contrib works for 7.3.x as
> well.. Or schedule a vacuum analyze every 15 minutes or so..
> >
Good Call. I'll give that a whirl and let you know.
> I think vacuum full is required.
>
D'oh. Would
From: "Shridhar Daithankar" <[EMAIL PROTECTED]>
> On 5 Aug 2003 at 10:29, Christopher Browne wrote:
>
> > Shridhar Daithankar wrote:
> > There would be some merit to having pg_autovacuum throw in some tables
> > in which to store persistent information,
>
> Well, the C++ version I wrote quite a whi
26 matches
Mail list logo
