On Fri, Jun 17, 2005 at 12:21:44PM -0400, Matthew T. O'Connor wrote:
>
> This will make VACUUM less painful, but it doesn't eliminate the need /
> desire for autovacuum. I agree this would be good, but I see it as a
> separate issue.
Not only is it a seperate issue, but there's also no way it
Christopher Browne wrote:
[EMAIL PROTECTED] (Gavin Sherry) wrote:
I guess the main point is, if something major like this ships in the
backend it says to users that the problem has gone away. pg_autovacuum is
a good contrib style solution: it addresses a problem users have and
attempts to so
Josh,
> Just so everyone knows from the get go here. I am purposely playing a
> little devils advocate.
Well, please stop it. We discussed AV over a year ago when we ran out of time
to integrate it with 8.0. This disucussion now is hindering any discussion
of what needs to be *done* to inte
On Fri, 2005-06-17 at 00:03 -0700, Joshua D. Drake wrote:
> Matthew T. O'Connor wrote:
> > Joshua D. Drake wrote:
> >
> >> Just my own two cents. First I am not knocking the work that has been
> >> on autovacuum. I am sure that it was a leap on its own to get it to
> >> work. However I will say
"Matthew T. O'Connor" writes:
> ... People just didn't like including libpq
> into the backend for reasons I don't remember.
One reason I can think of is that there would be global-symbol conflicts
--- libpq has copies of some backend routines, but they are not
identical.
In any case, the argu
[EMAIL PROTECTED] (Gavin Sherry) wrote:
> I guess the main point is, if something major like this ships in the
> backend it says to users that the problem has gone away. pg_autovacuum is
> a good contrib style solution: it addresses a problem users have and
> attempts to solve it the way other user
Russell Smith wrote:
On Fri, 17 Jun 2005 06:26 pm, Andreas Pflug wrote:
Qingqing Zhou wrote:
One reason of not using lib-pq is that this one has to wait for the
completion of each vacuum (we don't has async execution in libpq right?),
There *is* async execution in libpq, and it
Russell Smith wrote:
* Reduces the total amount of time the system spends vacuuming since it
only vacuums when needed.
Can be easily done with cron.
Can you do partial table vacuums with CRON?
You can work out the smartest time to vacuum with cron? I thought it just
scheduled task
Joshua D. Drake wrote:
Matthew T. O'Connor wrote:
The major reasons for autovacuum as I see it are as follows:
* Reduces administrative overhead having to keep track of what tables
need to be vacuumed how often.
Creates more overhead and thus reduces performance.
In the general case, I
Joshua D. Drake wrote:
Josh Berkus wrote:
I've personally seen at least a dozen user requests for "autovacuum
in the backend", and had this conversation about 1,100 times:
NB: "After a week, my database got really slow."
Me: "How often are you running VACUUM ANALYZE?"
NB: "Running what?"
On Fri, 17 Jun 2005, Russell Smith wrote:
> > Added to TODO:
> >
> > * Create a bitmap of pages that need vacuuming
> >
> >Instead of sequentially scanning the entire table, have the background
> >writer or some other process record pages that have expired rows, then
> >VACUUM can loo
On Fri, 17 Jun 2005, Russell Smith wrote:
> > >4) Related to this, I guess, is that a user's FSM settings might be
> > >completely inappropriate. The 'Just read the manual' or 'Just read the
> > >logs' argument doesn't cut it, because the main argument for autovacuum in
> > >the backend is that pe
On Fri, 17 Jun 2005 06:26 pm, Andreas Pflug wrote:
> Qingqing Zhou wrote:
> > "Tom Lane" <[EMAIL PROTECTED]> writes:
> >
> >>Yeah --- a libpq-based solution is not what I think of as integrated at
> >>all, because it cannot do anything that couldn't be done by the existing
> >>external autovacuum
> >4) Related to this, I guess, is that a user's FSM settings might be
> >completely inappropriate. The 'Just read the manual' or 'Just read the
> >logs' argument doesn't cut it, because the main argument for autovacuum in
> >the backend is that people do not and will not.
> >
> >
>
> Agreed, it
> Added to TODO:
>
> * Create a bitmap of pages that need vacuuming
>
>Instead of sequentially scanning the entire table, have the background
>writer or some other process record pages that have expired rows, then
>VACUUM can look at just those pages rather than the entire table. I
> > The major reasons for autovacuum as I see it are as follows:
> >
> > * Reduces administrative overhead having to keep track of what tables
> > need to be vacuumed how often.
>
> Creates more overhead and thus reduces performance.
Or reduces vacuum overhead because the vacuum strategy is much
Qingqing Zhou wrote:
"Tom Lane" <[EMAIL PROTECTED]> writes:
Yeah --- a libpq-based solution is not what I think of as integrated at
all, because it cannot do anything that couldn't be done by the existing
external autovacuum process. About all you can buy there is having the
postmaster spawn t
* Reduces the total amount of time the system spends vacuuming since
it only vacuums when needed.
Can be easily done with cron.
* Keeps stats up-to-date automatically
Which can be done with cron
* Eliminates newbie confusion
RTFM
* Eliminates one of the criticisms that the public has
Matthew T. O'Connor wrote:
Joshua D. Drake wrote:
Just my own two cents. First I am not knocking the work that has been
on autovacuum. I am sure that it was a leap on its own to get it to
work. However I will say that I just don't see the reason for it.
The major reasons for autovacuum as
Josh Berkus wrote:
Josh,
Just my own two cents. First I am not knocking the work that has been on
autovacuum. I am sure that it was a leap on its own to get it to work.
However I will say that I just don't see the reason for it.
I've personally seen at least a dozen user requests for "autov
Gavin,
For the record, I don't consider myself a PostgreSQL newbie, nor do I
manage any 2 TB databases (much less tables), but I do have an
unusual production use case: thousands (> 10,000) of tables, many of
them inherited, and many of them with hundreds of thousands (a few
with millions
Gavin Sherry wrote:
> In January I was in Toronto with Jan, Tom and others and some ideas about
> vacuum were being discussed. The basic idea is that when we dirty pages we
> need we set a bit in a bitmap to say that the page has been dirty. A
> convenient place to do this is when we are writing di
"Tom Lane" <[EMAIL PROTECTED]> writes:
>
> Yeah --- a libpq-based solution is not what I think of as integrated at
> all, because it cannot do anything that couldn't be done by the existing
> external autovacuum process. About all you can buy there is having the
> postmaster spawn the autovacuum
Josh Berkus wrote:
Alvaro,
coffee-with-cream vacuums.
I tried this and now my Hoover makes this horrible noise and smokes. ;-)
Probably related to the quality of American coffee ;).
All:
Seriously, all: when I said that "users" were asking for Autovac in the
backend (AVitB), I wasn't
Andrew Dunstan wrote:
Andreas Pflug wrote:
We're having a growing zoo of daemons that can be regarded as tightly
integrated server add-on processes (slony, autovac, pgAgent), and it
would be really nice (say: win32 users are used to it, thus requiring
it) to have a single point of contro
On Thu, 16 Jun 2005, Alvaro Herrera wrote:
> On Thu, Jun 16, 2005 at 04:20:34PM +1000, Gavin Sherry wrote:
>
> > 2) By no fault of its own, autovacuum's level of granularity is the table
> > level. For people dealing with non-trivial amounts of data (and we're not
> > talking gigabytes or terabyte
Andreas Pflug wrote:
We're having a growing zoo of daemons that can be regarded as tightly
integrated server add-on processes (slony, autovac, pgAgent), and it
would be really nice (say: win32 users are used to it, thus requiring
it) to have a single point of control.
Maybe a super daemo
Josh Berkus wrote:
Dave,
In previous discussions on -hackers when ppl raised the idea of
something like pgAgent being built into the backend, istm that the
majority of people were against the idea.
Well, you're up against the minimalist approach to core PostgreSQL there. It
would pretty m
On N, 2005-06-16 at 11:42 -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
...
> > Some people say "keep it simple and have one process per cluster." I
> > think they don't realize it's actually more complex, not the other way
> > around.
>
> Agreed. If you aren't connected t
Tom Lane wrote:
"Matthew T. O'Connor" writes:
I don't think you can use a dump to determine who should be connected to
next since you don't really know what happened since the last time you
exited. What was a priority 5 or 10 minutes ago might not be a priority
now.
Well, the info
"Matthew T. O'Connor" writes:
> I don't think you can use a dump to determine who should be connected to
> next since you don't really know what happened since the last time you
> exited. What was a priority 5 or 10 minutes ago might not be a priority
> now.
Well, the information necessary to
Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Now, I'm hearing people don't like using libpq.
Yeah --- a libpq-based solution is not what I think of as integrated at
all, because it cannot do anything that couldn't be done by the existing
external autovacuum process. Abo
Josh Berkus writes:
> Seriously, all: when I said that "users" were asking for Autovac in the
> backend (AVitB), I wasn't talking just the newbies on #postgresql. I'm also
> talking companies like Hyperic, and whole groups like the postgresql.org.br.
>
> This is a feature that people wan
Dave,
> In previous discussions on -hackers when ppl raised the idea of
> something like pgAgent being built into the backend, istm that the
> majority of people were against the idea.
Well, you're up against the minimalist approach to core PostgreSQL there. It
would pretty much *have* to be an
People,
> AVitB has been on the TODO list for 2 versions. There's been 2 years to
> question its position there. Now people are bringing up objections when
> there's no time for discussion left? This stinks.
Hmmm ... to be specific, I'm referring to the objections to the *idea* of
AVitB, no
Alvaro,
> coffee-with-cream vacuums.
I tried this and now my Hoover makes this horrible noise and smokes. ;-)
All:
Seriously, all: when I said that "users" were asking for Autovac in the
backend (AVitB), I wasn't talking just the newbies on #postgresql. I'm also
talking companies like Hyp
kers@postgresql.org
> Subject: Re: [HACKERS] Autovacuum in the backend
>
> Dave,
>
> i wonder if we should aim to have pgAgent in the backend
> which was one
> of the reasons why I considered to have it converted from C++
> to pure C.
In previous discussions on -hacke
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Now, I'm hearing people don't like using libpq.
Yeah --- a libpq-based solution is not what I think of as integrated at
all, because it cannot do anything that couldn't be done by the existing
external autovacuum process. About all you can buy there is
Alvaro Herrera wrote:
On Thu, Jun 16, 2005 at 04:20:34PM +1000, Gavin Sherry wrote:
2) By no fault of its own, autovacuum's level of granularity is the table
level. For people dealing with non-trivial amounts of data (and we're not
talking gigabytes or terabytes here), this is a serious drawba
On Thu, Jun 16, 2005 at 04:20:34PM +1000, Gavin Sherry wrote:
> 2) By no fault of its own, autovacuum's level of granularity is the table
> level. For people dealing with non-trivial amounts of data (and we're not
> talking gigabytes or terabytes here), this is a serious drawback. Vacuum
> at peak
On Thu, Jun 16, 2005 at 01:32:16AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > A question for interested parties. I'm thinking in handling the
> > user/password issue by reading the flat files (the copies of pg_shadow,
> > pg_database, etc).
>
> Er, what "user/password
Matthew T. O'Connor wrote:
Right, I think if VACUUM is improved than the semantics of AV in the
backend might change, but I think there will always be a need for some
maintenance, and a daemon that monitors the maintenance needs of your
database and fires off appropriate maintenance commands
On Wed, Jun 15, 2005 at 09:07:30PM -0700, Josh Berkus wrote:
> Josh,
>
> > Just my own two cents. First I am not knocking the work that has been on
> > autovacuum. I am sure that it was a leap on its own to get it to work.
> > However I will say that I just don't see the reason for it.
>
> I've p
Hans-Jürgen Schönig wrote:
I completly agree with Gavin - integrating this kind of thing into the
backend writer or integrate it with FSM would be the ideal solution.
Yes AV should look at FSM data, and it will eventually. I'm not sure
how you would integrate AV with the backend writer, but
Gavin Sherry wrote:
On Thu, 16 Jun 2005, Matthew T. O'Connor wrote:
Would you mind expounding on why you think autovacuum isn't suitable for
the general public? I know it's not a silver bullet, but I think in
general, it will be helpful for most people.
As I said, this is largely the
Andrew Dunstan wrote:
Gavin Sherry said:
I think this gets away from my point a little. People with 2 TB tables
can take care of themselves, as can people who've taken the time to
partition their tables to speed up vacuum. I'm more concerned about the
majority of people who fall in the middl
Gavin Sherry said:
> On Thu, 16 Jun 2005, [ISO-8859-1] Hans-Jürgen Schönig wrote:
>
>> > 2) By no fault of its own, autovacuum's level of granularity is the
>> > table level. For people dealing with non-trivial amounts of data
>> > (and we're not talking gigabytes or terabytes here), this is a
>> >
> -Original Message-
> From: Magnus Hagander [mailto:[EMAIL PROTECTED]
> Sent: 16 June 2005 10:15
> To: Josh Berkus; Gavin Sherry
> Cc: Bruce Momjian; pgsql-hackers@postgresql.org; Dave Page
> Subject: RE: [HACKERS] Autovacuum in the backend
>
> > If we
Gavin Sherry wrote:
On Thu, 16 Jun 2005, [ISO-8859-1] Hans-J�rgen Sch�nig wrote:
2) By no fault of its own, autovacuum's level of granularity is the table
level. For people dealing with non-trivial amounts of data (and we're not
talking gigabytes or terabytes here), this is a serious drawback.
On Thu, 16 Jun 2005, [ISO-8859-1] Hans-Jürgen Schönig wrote:
> > 2) By no fault of its own, autovacuum's level of granularity is the table
> > level. For people dealing with non-trivial amounts of data (and we're not
> > talking gigabytes or terabytes here), this is a serious drawback. Vacuum
> >
> If we do integrated AV, it should only be turned on by
> default at a relatively low level. And wasn't there an issue
> on Windows with AV not working?
AFAIK, it works.
But the fact that you need to provide it with a userid/password combo
makes it a lot harder to install as a service. And it'
2) By no fault of its own, autovacuum's level of granularity is the table
level. For people dealing with non-trivial amounts of data (and we're not
talking gigabytes or terabytes here), this is a serious drawback. Vacuum
at peak times can cause very intense IO bursts -- even with the
enhancements
On Thu, 16 Jun 2005, Matthew T. O'Connor wrote:
> Gavin Sherry wrote:
>
> >I guess my main concern is that we'll have a solution to the problem of
> >dead tuples which is only half way there. It is only an incremental
> >improvement upon the contrib module and solves only one real problem:
> >user
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> A question for interested parties. I'm thinking in handling the
> user/password issue by reading the flat files (the copies of pg_shadow,
> pg_database, etc).
Er, what "user/password issue"? Context please.
> The only thing that I'd need to modify is
On Thu, 2005-06-16 at 00:44 -0400, Matthew T. O'Connor wrote:
> Joshua D. Drake wrote:
>
> > Just my own two cents. First I am not knocking the work that has been
> > on autovacuum. I am sure that it was a leap on its own to get it to
> > work. However I will say that I just don't see the reason
Neil Conway wrote:
Alvaro Herrera wrote:
One issue I do have to deal with right now is how many autovacuum
processes do we want to be running. The current approach is to have one
autovacuum process. Two possible options would be to have one per
database, and one per tablespace. What do peop
Alvaro Herrera wrote:
On Thu, Jun 16, 2005 at 02:09:47PM +1000, Neil Conway wrote:
Alvaro Herrera wrote:
One issue I do have to deal with right now is how many autovacuum
processes do we want to be running. The current approach is to have one
autovacuum process. Two possible options
Neil Conway wrote:
Josh Berkus wrote:
> Wheras integrated AV is something we *could* do, and is widely
desired.
I don't see why. IMHO the current autovacuum approach is far from
optimal. If "integrated autovacuum" just means taking the same
approach and building it into the backend, how do
Joshua D. Drake wrote:
Just my own two cents. First I am not knocking the work that has been
on autovacuum. I am sure that it was a leap on its own to get it to
work. However I will say that I just don't see the reason for it.
The major reasons for autovacuum as I see it are as follows:
* R
Gavin Sherry wrote:
I guess my main concern is that we'll have a solution to the problem of
dead tuples which is only half way there. It is only an incremental
improvement upon the contrib module and solves only one real problem:
users do not read up on VACUUM or autovacuum. This is at the expen
On Thu, Jun 16, 2005 at 02:09:47PM +1000, Neil Conway wrote:
> Alvaro Herrera wrote:
> >One issue I do have to deal with right now is how many autovacuum
> >processes do we want to be running. The current approach is to have one
> >autovacuum process. Two possible options would be to have one per
I've personally seen at least a dozen user requests for "autovacuum in the
backend", and had this conversation about 1,100 times:
NB: "After a week, my database got really slow."
Me: "How often are you running VACUUM ANALYZE?"
NB: "Running what?"
Me too. Just hang out in #postgresql for a whi
Josh Berkus wrote:
Not that I don't agree that we need a less I/O intense alternative to VACUUM,
but it seems unlikely that we could actually do this, or even agree on a
spec, before feature freeze.
I don't see the need to rush anything in before the feature freeze.
> Wheras integrated AV is
Josh,
> Just my own two cents. First I am not knocking the work that has been on
> autovacuum. I am sure that it was a leap on its own to get it to work.
> However I will say that I just don't see the reason for it.
I've personally seen at least a dozen user requests for "autovacuum in the
backe
Alvaro Herrera wrote:
One issue I do have to deal with right now is how many autovacuum
processes do we want to be running. The current approach is to have one
autovacuum process. Two possible options would be to have one per
database, and one per tablespace. What do people think?
Why do we
Alvaro,
> One issue I do have to deal with right now is how many autovacuum
> processes do we want to be running. The current approach is to have one
> autovacuum process. Two possible options would be to have one per
> database, and one per tablespace. What do people think?
I'd vote for one,
On Wed, Jun 15, 2005 at 11:42:17PM -0400, Matthew T. O'Connor wrote:
> Alvaro Herrera wrote:
>
> >A question for interested parties. I'm thinking in handling the
> >user/password issue by reading the flat files (the copies of pg_shadow,
> >pg_database, etc).
> >
> >The only thing that I'd need to
The big leap will be to get it in the backend, which will as Chris KL suggested
stop people shooting themselves in the foot.
I'm not sure what strict rules are imposed by Feature freeze, but there may be
time for others to make some improvements before 8.1.
We have also looked at this for at l
On Wed, 15 Jun 2005, Alvaro Herrera wrote:
> On Thu, Jun 16, 2005 at 11:07:31AM +1000, Gavin Sherry wrote:
> > On Wed, 15 Jun 2005, Bruce Momjian wrote:
> >
> > > I am going to start working on it. I am concerned it is a big job.
> > >
> > > I will post questions as I find them, and the one below
Alvaro Herrera wrote:
A question for interested parties. I'm thinking in handling the
user/password issue by reading the flat files (the copies of pg_shadow,
pg_database, etc).
The only thing that I'd need to modify is add the datdba field to
pg_database, so we can figure out an appropiate use
Gavin, People,
> I'm wondering if effort is being misdirected here. I remember when Mark
> Wong at OSDL was running pg_autovacuum during a dbt run, he was seeing
> significant performance loss -- I think on the order of 30% to 40% (I will
> try and dig up a link to the results).
It wasn't quite t
On Thu, 16 Jun 2005 12:54 pm, Alvaro Herrera wrote:
> On Thu, Jun 16, 2005 at 11:07:31AM +1000, Gavin Sherry wrote:
> > On Wed, 15 Jun 2005, Bruce Momjian wrote:
> >
> > > I am going to start working on it. I am concerned it is a big job.
> > >
> > > I will post questions as I find them, and the
On Thu, Jun 16, 2005 at 11:07:31AM +1000, Gavin Sherry wrote:
> On Wed, 15 Jun 2005, Bruce Momjian wrote:
>
> > I am going to start working on it. I am concerned it is a big job.
> >
> > I will post questions as I find them, and the one below is a good one.
>
> I'm wondering if effort is being m
A question for interested parties. I'm thinking in handling the
user/password issue by reading the flat files (the copies of pg_shadow,
pg_database, etc).
The only thing that I'd need to modify is add the datdba field to
pg_database, so we can figure out an appropiate user for vacuuming each
data
I totally agree. I think we know pg_autovacuum is just a short-term
solution. What we need is for someone to take the lead in this.
The TODO list has the ideas documented. There is no reason the
background writer could not load the FSM directly with free pages.
---
um, can we have these as separate GUCs and not lumped together as a
string? i.e.:
autovacuum_frequency = 60 #seconds, 0 = disable
autovacuum_vacuum_threshold = 200
autovacuum_vacuum_multiple = 0.5
autovacuum_analyze_threshold = 100
autovacuum_analyze_multiple = 0.4
AV should be disabled by def
On Wed, 15 Jun 2005, Bruce Momjian wrote:
>
> I am going to start working on it. I am concerned it is a big job.
>
> I will post questions as I find them, and the one below is a good one.
>
I'm wondering if effort is being misdirected here. I remember when Mark
Wong at OSDL was running pg_autova
Matthew T. O'Connor wrote:
> I don't think the current implementation if VACUUM can support that. I
> believe that all the work will get rolled back if gets canceled.
>
> Perhaps a decent solution would be to have autovacuum increase the
> vacuum delay settings dynamically based on system load
Hannu Krosing wrote:
Can autovacuum yet be configured _not_ to run vacuum during some hours
or above some load ?
That is certainly a goal, hopefully it will get done for 8.1.The
actual design I had in mind (based on prior discussion on hackers) is to
allow a maintenance window that wo
Josh Berkus wrote:
Qingqing,
add a parameter to let user pass in the configuration parameters:
* autovacuum_command = "-s 100 -S 1 ..."
um, can we have these as separate GUCs and not lumped together as a string?
i.e.:
autovacuum_frequency = 60 #seconds, 0 = disable
autovacuum_vacu
Bruce Momjian wrote:
I am going to start working on it. I am concerned it is a big job.
I will post questions as I find them, and the one below is a good one.
It is a big question, at least it's the main stumbling block I had, and
it's the one that kept my work from being integrated into
Bruce Momjian wrote:
Hannu Krosing wrote:
On K, 2005-06-15 at 13:41 +0800, Qingqing Zhou wrote:
"Neil Conway" <[EMAIL PROTECTED]> writes
Wasn't the plan to rewrite pg_autovacuum to use the FSM rather than the
stats collector?
Yes, those are step five. The TODO list h
Qingqing,
> add a parameter to let user pass in the configuration parameters:
> * autovacuum_command = "-s 100 -S 1 ..."
um, can we have these as separate GUCs and not lumped together as a string?
i.e.:
autovacuum_frequency = 60 #seconds, 0 = disable
autovacuum_vacuum_threshold = 200
autovacuu
Alvaro Herrera wrote:
> On Wed, Jun 15, 2005 at 11:23:20AM +0800, Qingqing Zhou wrote:
>
> > > Who would like to get started on this? It seems pretty straight-forward.
> >
> > I'd like to give it a try.
>
> I'm on it. I have Matthew's patch, updated to current sources, and I'm
> working on cle
I am going to start working on it. I am concerned it is a big job.
I will post questions as I find them, and the one below is a good one.
---
Qingqing Zhou wrote:
>
> "Qingqing Zhou" <[EMAIL PROTECTED]> writes
> >
> > The
On Wed, Jun 15, 2005 at 11:23:20AM +0800, Qingqing Zhou wrote:
> > Who would like to get started on this? It seems pretty straight-forward.
>
> I'd like to give it a try.
I'm on it. I have Matthew's patch, updated to current sources, and I'm
working on cleaning it up to address all known conce
Hannu Krosing wrote:
> On K, 2005-06-15 at 13:41 +0800, Qingqing Zhou wrote:
> > "Neil Conway" <[EMAIL PROTECTED]> writes
> > >
> > > Wasn't the plan to rewrite pg_autovacuum to use the FSM rather than the
> > > stats collector?
> > >
> >
> > I don't understand. Currently the basic logic of pg_aut
"Qingqing Zhou" <[EMAIL PROTECTED]> writes
>
> The start/stop routine is quite like Bgwriter.
>
I just realized that the non-standard backend can't execute any SQL command.
If so, how would the background pg_autovacuum do "vacuum"? It could be
forked more like a standard backend, but this is obvi
On K, 2005-06-15 at 13:41 +0800, Qingqing Zhou wrote:
> "Neil Conway" <[EMAIL PROTECTED]> writes
> >
> > Wasn't the plan to rewrite pg_autovacuum to use the FSM rather than the
> > stats collector?
> >
>
> I don't understand. Currently the basic logic of pg_autovacuum is to use the
> pg_stat_all_t
On T, 2005-06-14 at 21:23 -0400, Bruce Momjian wrote:
> One goal for 8.1 is to move /contrib/pg_autovacuum in to the backend. I
> think it has to be done in four stages:
>
> o move it into the backend and have it start/stop automatically
> o move the autovacuum configuration paramet
"Neil Conway" <[EMAIL PROTECTED]> writes
>
> Wasn't the plan to rewrite pg_autovacuum to use the FSM rather than the
> stats collector?
>
I don't understand. Currently the basic logic of pg_autovacuum is to use the
pg_stat_all_tables numbers like n_tup_upd, n_tup_del to determine if a
relation ne
Qingqing Zhou wrote:
The start/stop routine is quite like Bgwriter. It requires PgStats to be
turned on.
Wasn't the plan to rewrite pg_autovacuum to use the FSM rather than the
stats collector?
-Neil
---(end of broadcast)---
TIP 3: if posting/
"Tom Lane" <[EMAIL PROTECTED]> writes
>
> A small problem here is that until you get at least to step 3
> (backend-standard error handling), none of it is going to be acceptable
> to commit. So I don't entirely buy Bruce's notion of bite-size pieces
> of work. You can certainly work on it in tha
"Bruce Momjian" writes
>
> One goal for 8.1 is to move /contrib/pg_autovacuum in to the backend. I
> think it has to be done in four stages:
>
> o move it into the backend and have it start/stop automatically
The start/stop routine is quite like Bgwriter. It requires PgStats to be
turned on. If
Bruce Momjian writes:
> One goal for 8.1 is to move /contrib/pg_autovacuum in to the backend. I
> think it has to be done in four stages:
> o move it into the backend and have it start/stop automatically
> o move the autovacuum configuration parameters into postgresql.conf
>
One goal for 8.1 is to move /contrib/pg_autovacuum in to the backend. I
think it has to be done in four stages:
o move it into the backend and have it start/stop automatically
o move the autovacuum configuration parameters into postgresql.conf
o modify the code to use
96 matches
Mail list logo
