Tom Lane wrote:
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
I probably said that wrong, but how do backends get their stats data?
They read it out of a flat file that the stats collector rewrites every
so often.
Ok so that would be easy to do (if we decide we want to)
Is that rea
On Mon, Mar 22, 2004 at 04:50:57PM -0500, Matthew T. O'Connor wrote:
> Could you please explain this better, I don't really understand what the
> problem is. If you want pg_autovacuum to perform a vacuum on a table
> that has had exactly X updates no matter what, you can just run it with
> -V0
Matthew T. O'Connor wrote:
Joe Conway wrote:
This would be *really* nice to have. In my recent case, if
pg_autovacuum could work for say 3 minutes, and then back off for 2
minutes or so while the batch transactions hit, it would be ideal.
I'm not sure what you are suggesting here. As it stands
Matthew T. O'Connor wrote:
Could you please explain this better, I don't really understand what the
problem is. If you want pg_autovacuum to perform a vacuum on a table
that has had exactly X updates no matter what, you can just run it with
-V0 -vX (where X is the vacuum threshold) same thing
Gavin Sherry wrote:
I was initially against the idea of using libpq but its growing on me too.
I think it would be good if the core functions of pg_autovacuum: threshold
algorithms, connection, issuing commands can be (re?)designed such that
not only the backend can link against it but also a str
Joe Conway wrote:
Matthew T. O'Connor wrote:
* Inability to schedule vacuums during off-peak times
This would be *really* nice to have. In my recent case, if
pg_autovacuum could work for say 3 minutes, and then back off for 2
minutes or so while the batch transactions hit, it would be ideal.
Matthew T. O'Connor wrote:
* Inability to customize thresholds on a per table basis
I ran headlong into this one. IMHO fixing this is critical.
* Inability to set default thresholds on a per database basis
* Inability to exclude specific databases / tables from pg_autovacuum
monitoring
These would
On Mon, 22 Mar 2004, Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > Well this certainly sounds like something that would be easy to do,
> > which appeals to me at least as a first cut. Question: Does this mean
> > that I lose many of the advantages of being "in the backen
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> There is no "direct pipe connection" to the stats collector,
> I probably said that wrong, but how do backends get their stats data?
They read it out of a flat file that the stats collector rewrites every
so often.
> Meanin
Tom Lane wrote:
If you aren't a backend then you couldn't safely access shared memory,
including FSM in particular. I see no reason you couldn't use GUC
though. There is no "direct pipe connection" to the stats collector,
except in the output direction which is not what you want, so I'm not
seei
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Well this certainly sounds like something that would be easy to do,
> which appeals to me at least as a first cut. Question: Does this mean
> that I lose many of the advantages of being "in the backend"? That is,
> would pg_autovacuum still b
Alex J. Avriette wrote:
Hi, Matthew. For our uses, we found that pg_autovacuum did not behave
as expected with vacuum_threshold set to 0. For our purposes, we have
a very good idea of how many tuples need to be slurped up over a given
interval, and would like the autovacuum daemon to simply go th
Tom Lane wrote:
From the point of view of the postmaster a GUC-controlled delay would
seem like the best thing. We could discuss having the autovacuum code
try to feed back adjustments in the delay, but remember that one of the
golden virtues for the postmaster proper is simplicity; that translat
> > As such, I
> > think that a vacuum backend for a specific database should be forked upon
> > the first connect. Also, the backend might like to try and workout if
> > there are any active backends for its database every so often and if not,
> > perform a final vacuum (if necessary) and exit, so
On Sun, Mar 21, 2004 at 05:32:59PM -0500, Matthew T. O'Connor wrote:
> Lately I have been thinking about the next steps for the pg_autovacuum
> daemon. I have written up a document that describes what I'm planning
> to do next. Please read the attached and response as I would really
> like some
On Mon, 2004-03-22 at 10:51, Tom Lane wrote:
> > 2.Use a config file. This would require some additional coding to add
> > the required parsing, but is possible.
>
> Personally I like #2. The claim that this requires extra code seems
> bogus to me --- when you are working at the C code level,
On Mon, 2004-03-22 at 04:23, Karel Zak wrote:
> All. It's important do it as backend process. Because libpq has very,
> very limited and slow resources for work with backend stuff.
Agreed.
> The base should be the standard backend with different "main loop" that
> will instead socket chec
On Mon, 2004-03-22 at 10:58, Tom Lane wrote:
> Lots of idle processes sitting around is right out, too. Remember that
> each one would eat a backend connection slot. I think we are going to
> have to limit this to *one* process at a time. What that probably means
> is that we successively launch
On Mon, 2004-03-22 at 07:25, Richard Huxton wrote:
> On Monday 22 March 2004 03:36, Matthew T. O'Connor wrote:
> > 1.Store config data inside a special pg_autovacuum table inside
> > existing databases that wants custom settings.
> >
> > 2.Use a config file. This would require some additional co
Gavin Sherry <[EMAIL PROTECTED]> writes:
> One point is this: vacuum() assumes that you are running in a fully
> fledged backend. There'd be a fair bit of work involved in allowing a
> single process to call vacuum() against multiple databases.
Make that "it isn't going to happen".
> As such, I
>
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> There are differing opinions as to the best way to providing these this
> feature. The primary debate is where to save the configuration data. I
> see three options:
> 1.Store config data inside a special pg_autovacuum table inside
> existing
On Mon, 2004-03-22 at 03:36, Gavin Sherry wrote:
> One point is this: vacuum() assumes that you are running in a fully
> fledged backend. There'd be a fair bit of work involved in allowing a
> single process to call vacuum() against multiple databases.
I can't imagine we want to do that.
> As su
Gavin Sherry wrote:
On Sun, 21 Mar 2004, Matthew T. O'Connor wrote:
On Sun, 2004-03-21 at 20:31, Christopher Kings-Lynne wrote:
> > I think these configuration issues will become a lot easier if you make
> > the autovacuum daemon a subprocess of the postmaster (like, say, the
> > checkpoint proces
On Monday 22 March 2004 03:36, Matthew T. O'Connor wrote:
> 1. Per Database defaults and Per table Thresholds:
>
> There are differing opinions as to the best way to providing these this
> feature. The primary debate is where to save the configuration data. I
> see three options:
>
> 1.Store con
On Mon, Mar 22, 2004 at 02:35:37AM -0500, Matthew T. O'Connor wrote:
> On Sun, 2004-03-21 at 23:00, Bruce Momjian wrote:
> > > > C) Most importantly, I'm not backend hacker. If someone wants to do the
> > > > initial work of getting it running as a backend process, I can take it
> > > > from there
> > Ok, thanks for the offer to help, but I think I understated things above
> > when I said I'll need a "little" help :-)
> >
>
> I haven't looked at the code but...
>
> > I have a few big picture questions. Once pg_autovacuum is launched as a
> > postmaster sub-process, what changes? That is, c
On Mon, 22 Mar 2004, Matthew T. O'Connor wrote:
> On Sun, 2004-03-21 at 23:00, Bruce Momjian wrote:
> > > > C) Most importantly, I'm not backend hacker. If someone wants to do the
> > > > initial work of getting it running as a backend process, I can take it
> > > > from there. A while ago, Bruc
> > B) Perhaps people like the idea of it being a client app (I don't think
> > so.)
> >
>
> I'd like to see it as part of the backend.
>
> > C) Most importantly, I'm not backend hacker. If someone wants to do the
> > initial work of getting it running as a backend process, I can take it
> > fro
On Sun, 21 Mar 2004, Matthew T. O'Connor wrote:
> On Sun, 2004-03-21 at 20:31, Christopher Kings-Lynne wrote:
> > > I think these configuration issues will become a lot easier if you make
> > > the autovacuum daemon a subprocess of the postmaster (like, say, the
> > > checkpoint process). Then yo
On Sun, 2004-03-21 at 18:12, Tom Lane wrote:
> "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> > [ rtf document ]
>
> Please repost in some less proprietary format. Plain text is generally
> considered the thing to use on this list.
I don't think RTF is proprietary but I should have just pos
On Sun, 2004-03-21 at 20:31, Christopher Kings-Lynne wrote:
> > I think these configuration issues will become a lot easier if you make
> > the autovacuum daemon a subprocess of the postmaster (like, say, the
> > checkpoint process). Then you have access to a host of methods for
> > storing sta
I think these configuration issues will become a lot easier if you make
the autovacuum daemon a subprocess of the postmaster (like, say, the
checkpoint process). Then you have access to a host of methods for
storing state, handling configuration, etc.
Yeah - why delay making it a backend proces
Matthew T. O'Connor wrote:
> Lately I have been thinking about the next steps for the
> pg_autovacuum daemon. I have written up a document that describes
> what I'm planning to do next. Please read the attached and response
> as I would really like some feedback.
I think these configuration iss
Ð ÐÐÐ, 22.03.2004, Ð 00:12, Tom Lane ÐÐÑÐÑ:
> Please repost in some less proprietary format. Plain text is generally
> considered the thing to use on this list.
--
Markus Bertheau <[EMAIL PROTECTED]>
pg_autovacuum Version 2
Design Document:
Exec Summary:
pg_autovacuum was initially released as
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes:
> Lately I have been thinking about the next steps for the pg_autovacuum
> daemon. I have written up a document that describes what I'm planning
> to do next. Please read the attached and response as I would really
> like some feedback.
> [ rtf
35 matches
Mail list logo
