Peter Eisentraut wrote:
Guillaume Smet wrote:
IMHO, we shoud also change superuser_reserved_connections from 2 to 3
because one of the connections will be used by autovacuum.
Yes, good point.
Done, because most people will turn autovacuum on, even if it isn't on
by default.
--
Bruce
Bruce Momjian wrote:
Done, because most people will turn autovacuum on, even if it isn't on
by default.
I wonder how many distros will turn on autovacuum as well, making it the
de-facto standard anyway.
Regards,
---(end of broadcast)---
TIP
Andreas Pflug wrote:
Bruce Momjian wrote:
Done, because most people will turn autovacuum on, even if it isn't on
by default.
I wonder how many distros will turn on autovacuum as well, making it the
de-facto standard anyway.
Win32 already does.
--
Bruce Momjian [EMAIL
On Tue, Aug 29, 2006 at 09:23:53PM -0700, Josh Berkus wrote:
Peter,
OK, it seems that while everyone wants autovacuum be more aggressive by
default, no one has any good data to support one setting or another. I
so I suggest that we just cut scale factor and base threshold in half
right
Peter,
OK, it seems that while everyone wants autovacuum be more aggressive by
default, no one has any good data to support one setting or another. I
so I suggest that we just cut scale factor and base threshold in half
right now (so it'd be 0.2, 0.1, 500, 250) and see about a
Folks,
all, even after 100% row replacement.
Er, even after 1000% row replacement.
--
Josh Berkus
PostgreSQL @ Sun
San Francisco
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
Jim C. Nasby [EMAIL PROTECTED] writes:
If we've got command stats turned on by default now, I'll have a hard
time buying performance as any reason to turn the others off.
That's a mistaken argument, because the reason stats_command_string
is now on is that it was reimplemented in a way that has
Jim C. Nasby wrote:
I thought we had agreed it would be a good idea to turn autovac_delay
on?
We had not, because there was no experience available about where to put
the default numbers.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
On 8/25/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Summarizing this thread, I see support for the following:
- autovacuum set to on by default in 8.2.
- stats_row_level also defaults to on.
- Delayed vacuum and delayed autovacuum will stay disabled.
- Scale factor set to 0.08 (vacuum) and
Guillaume Smet wrote:
IMHO, we shoud also change superuser_reserved_connections from 2 to 3
because one of the connections will be used by autovacuum.
Yes, good point.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of
Matthew T. O'Connor wrote:
That seems a big jump. BTW, I know .08 and .04 were suggested, but I
didn't see confirmation that it was a good idea. I know my initial
values were grossly over-conservative, but I am concerned about
bogging down the server with lots of vacuums, especially since we
Summarizing this thread, I see support for the following:
- autovacuum set to on by default in 8.2.
- stats_row_level also defaults to on.
(Perhaps stats_block_level should also default to on so it's not inconsistent,
seeing that everything else in on, too.)
- Delayed vacuum and delayed
Peter Eisentraut wrote:
Summarizing this thread, I see support for the following:
- autovacuum set to on by default in 8.2.
Yes.
- stats_row_level also defaults to on.
Yes.
(Perhaps stats_block_level should also default to on so it's not inconsistent,
seeing that everything else in on,
Am Freitag, 25. August 2006 17:32 schrieb Matthew T. O'Connor:
While there is talk of removing this all together, I think it was also
agreed that as long as these values are there, they should be reduced.
I think the defaults in 8.1 are 1000/500, I think 200/100 was suggested.
I'm thinking
Matthew T. O'Connor matthew@zeut.net writes:
Peter Eisentraut wrote:
- Leave base thresholds alone (pending further analysis that might remove
them
altogether?)
While there is talk of removing this all together, I think it was also
agreed that as long as these values are there, they
Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net writes:
While there is talk of removing this all together, I think it was also
agreed that as long as these values are there, they should be reduced.
I think the defaults in 8.1 are 1000/500, I think 200/100 was suggested.
ISTM
Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net writes:
Peter Eisentraut wrote:
- Leave base thresholds alone (pending further analysis that might remove
them
altogether?)
While there is talk of removing this all together, I think it was also
agreed that as long as these
On Fri, Aug 25, 2006 at 12:16:33PM -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Matthew T. O'Connor matthew@zeut.net writes:
Peter Eisentraut wrote:
- Leave base thresholds alone (pending further analysis that might
remove them
altogether?)
While there is talk of removing
Jim C. Nasby wrote:
On Tue, Aug 22, 2006 at 11:08:49AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
If there's a bunch of activity on a table but stats are reset
before a vacuum is run on it and then a vacuum is run, the user
will still be left thinking that the table needs
Larry Rosenman wrote:
Jim C. Nasby wrote:
On Tue, Aug 22, 2006 at 11:08:49AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
If there's a bunch of activity on a table but stats are reset
before a vacuum is run on it and then a vacuum is run, the user
will still be left
Alvaro Herrera [EMAIL PROTECTED] writes:
I think there is a reasonable case for saying that a manual vacuum could
hint pgstat to create the entry instead.
The problem with that is that a simple VACUUM; would force pgstat to
populate its entire hashtable. Which more or less defeats the idea of
On Thu, Aug 24, 2006 at 09:58:10AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think there is a reasonable case for saying that a manual vacuum could
hint pgstat to create the entry instead.
The problem with that is that a simple VACUUM; would force pgstat to
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Aug 24, 2006 at 09:58:10AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think there is a reasonable case for saying that a manual vacuum could
hint pgstat to create the entry instead.
The problem with that is that a simple
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Aug 24, 2006 at 09:58:10AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think there is a reasonable case for saying that a manual vacuum could
hint pgstat to create the entry instead.
The problem with
On Thu, Aug 24, 2006 at 01:48:50PM -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Thu, Aug 24, 2006 at 09:58:10AM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
I think there is a reasonable case for saying that a manual vacuum
On Tue, Aug 22, 2006 at 11:08:49AM -0400, Tom Lane wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
If there's a bunch of activity on a table but stats are reset before a
vacuum is run on it and then a vacuum is run, the user will still be
left thinking that the table needs to be vacuumed.
On Wed, Aug 23, 2006 at 01:45:43PM +0900, ITAGAKI Takahiro wrote:
Jim C. Nasby [EMAIL PROTECTED] wrote:
And +1 on Rod's suggestion to make it more aggressive. I always drop the
scale factor to at least 0.2 and 0.1 (though 0.1 and 0.05 don't seem
unreasonable), and typically drop the
Going back on-list...
On Tue, Aug 22, 2006 at 08:47:04AM -0400, Alvaro Herrera wrote:
Jim Nasby wrote:
On Aug 17, 2006, at 3:19 PM, Alvaro Herrera wrote:
Nevermind -- it's just that if you vacuum a table which you haven't
touched (insert, update, delete) since the last stats reset, then
Jim C. Nasby [EMAIL PROTECTED] writes:
If there's a bunch of activity on a table but stats are reset before a
vacuum is run on it and then a vacuum is run, the user will still be
left thinking that the table needs to be vacuumed.
Except that autovac *won't* vacuum it if the stats have been
Jim C. Nasby [EMAIL PROTECTED] wrote:
And +1 on Rod's suggestion to make it more aggressive. I always drop the
scale factor to at least 0.2 and 0.1 (though 0.1 and 0.05 don't seem
unreasonable), and typically drop the thresholds to 200 and 100 (though
again, lower is probably warrented).
Am Donnerstag, 17. August 2006 18:40 schrieb Josh Berkus:
I'm in favor of this, but do we want to turn on vacuum_delay by default
as well?
People might complain that suddenly their vacuum runs take four times as long
(or whatever). Of course, if we turn on autovacuum and advocate a more or
Peter Eisentraut wrote:
Am Donnerstag, 17. August 2006 18:40 schrieb Josh Berkus:
I'm in favor of this, but do we want to turn on vacuum_delay by default
as well?
People might complain that suddenly their vacuum runs take four times as long
(or whatever). Of course, if we turn on autovacuum
Peter Eisentraut [EMAIL PROTECTED] writes:
Does anyone, for that matter, want to propose possible default parameters for
vacuum_delay?
I haven't seen any sign that anyone's done any serious testing of delay
parameters, so I don't think we have the data needed to select some
defaults ...
Is it time to turn on autovacuum by default in 8.2? I know
we wanted to be on the side of caution with 8.1, but perhaps
we should evaluate the experiences now. Comments?
FWIW, the win32 installer has enalbed autovacuum by default already in
8.1. So it's definitly received a fair amount of
Peter Eisentraut wrote:
Is it time to turn on autovacuum by default in 8.2? I know we wanted to
be on the side of caution with 8.1, but perhaps we should evaluate the
experiences now. Comments?
Would be fine by me, but I'm curious to see what the community has to
say. A few comments:
On Thu, 2006-08-17 at 18:32 +0200, Peter Eisentraut wrote:
Is it time to turn on autovacuum by default in 8.2? I know we wanted to
be on the side of caution with 8.1, but perhaps we should evaluate the
experiences now. Comments?
I would say yes.
I use it on 2 databases over the 200GB mark
Matthew T. O'Connor wrote:
Peter Eisentraut wrote:
Is it time to turn on autovacuum by default in 8.2? I know we wanted to
be on the side of caution with 8.1, but perhaps we should evaluate the
experiences now. Comments?
Would be fine by me, but I'm curious to see what the community
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Would be fine by me, but I'm curious to see what the community has to
say. A few comments:
Autovacuum can cause unpredictable performance issues, that is if it
vacuums in the middle of a busy day and people don't want that, of
course they
Rod Taylor wrote:
The defaults could be a little more aggressive for both vacuum and
analyze scale_factor settings; 10% and 5% respectively.
I would agree with this, not sure of 10%/5% are right, but the general
feedback I have heard is that while the defaults in 8.1 are much better
than the
Matthew T. O'Connor wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Would be fine by me, but I'm curious to see what the community has to
say. A few comments:
Autovacuum can cause unpredictable performance issues, that is if it
vacuums in the middle of a busy day and
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
and increasing the log level when autovacuum actually fires off a VACUUM
or ANALYZE command.
This was not done because the logging control only for autovacuum was
going to be added. Right now, if you want to see the vacuum activity,
you
Peter,
Is it time to turn on autovacuum by default in 8.2? I know we wanted to
be on the side of caution with 8.1, but perhaps we should evaluate the
experiences now. Comments?
I'm in favor of this, but do we want to turn on vacuum_delay by default
as well?
--Josh
Matthew T. O'Connor wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
and increasing the log level when autovacuum actually fires off a VACUUM
or ANALYZE command.
This was not done because the logging control only for autovacuum was
going to be added. Right now, if
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
and increasing the log level when autovacuum actually fires off a VACUUM
or ANALYZE command.
This was not done because the logging control only for autovacuum was
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Any chance we can make this change before release? I think it's very
important to be able to look through the logs and *know* that you tables
are getting vacuumed or not.
Agreed. I just IM'ed Alvaro and he says pg_stat_activity should
Alvaro Herrera wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
and increasing the log level when autovacuum actually fires off a
VACUUM or ANALYZE command.
This was not done because the logging control only for autovacuum
was
Josh Berkus wrote:
Is it time to turn on autovacuum by default in 8.2? I know we wanted
to be on the side of caution with 8.1, but perhaps we should evaluate
the experiences now. Comments?
I'm in favor of this, but do we want to turn on vacuum_delay by default
as well?
I thought about
On Thu, Aug 17, 2006 at 12:41:57PM -0400, Matthew T. O'Connor wrote:
Peter Eisentraut wrote:
Is it time to turn on autovacuum by default in 8.2? I know we wanted to
be on the side of caution with 8.1, but perhaps we should evaluate the
experiences now. Comments?
Would be fine by me, but
Alvaro Herrera wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
and increasing the log level when autovacuum actually fires off a
VACUUM
or ANALYZE command.
This was not done because the logging
Larry Rosenman wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
and increasing the log level when autovacuum actually fires off a
VACUUM or ANALYZE command.
This was not done because the logging
Bruce Momjian wrote:
Larry Rosenman wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
and increasing the log level when autovacuum actually fires off
a VACUUM or ANALYZE command.
This was not done because
Larry Rosenman wrote:
Bruce Momjian wrote:
Larry Rosenman wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
and increasing the log level when autovacuum actually fires off
a VACUUM or ANALYZE command.
Matthew T. O'Connor wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Any chance we can make this change before release? I think it's very
important to be able to look through the logs and *know* that you tables
are getting vacuumed or not.
Agreed. I just IM'ed Alvaro
Jim C. Nasby wrote:
On Thu, Aug 17, 2006 at 12:41:57PM -0400, Matthew T. O'Connor wrote:
Would be fine by me, but I'm curious to see what the community has to
say. A few comments:
Autovacuum can cause unpredictable performance issues, that is if it
vacuums in the middle of a busy day and
Larry Rosenman wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Well, the problem is that it shows what it's *currently* doing, but it
doesn't let you know what has happened in the last day or whatever.
It can't answer has table foo been vacuumed recently? or what
tables haven't been
Matthew T. O'Connor wrote:
Jim C. Nasby wrote:
Actually, on a table small enough for the thresholds to kick in it's
going to be extremely fast to vacuum anyway, and the table is probably
either static or changing very rapidly. I'm wondering if maybe they
should just default to 0?
I
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
I assume you are suggesting that the base value be 0? Well for one
thing if the table doesn't have any rows that will result in constant
vacuuming of that table, so it needs to be greater than 0. For a small
table, say 100 rows, there
On Thu, Aug 17, 2006 at 01:29:57PM -0400, Matthew T. O'Connor wrote:
Josh Berkus wrote:
Is it time to turn on autovacuum by default in 8.2? I know we wanted
to be on the side of caution with 8.1, but perhaps we should evaluate
the experiences now. Comments?
I'm in favor of this, but do
On Thu, Aug 17, 2006 at 01:47:37PM -0400, Matthew T. O'Connor wrote:
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
I assume you are suggesting that the base value be 0? Well for one
thing if the table doesn't have any rows that will result in constant
vacuuming of that table, so it
Bruce Momjian [EMAIL PROTECTED] writes:
Agreed. I just IM'ed Alvaro and he says pg_stat_activity should now
show exactly what autovacuum is doing (and if it doesn't, let's fix it).
I think that is the best solution to the monitoring problem, rather than
throwing lines in the server logs.
How
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Any chance we can make this change before release? I think it's very
important to be able to look through the logs and *know* that you tables
are getting vacuumed or not.
On Thu, Aug 17, 2006 at 03:17:07PM -0400, Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Agreed. I just IM'ed Alvaro and he says pg_stat_activity should now
show exactly what autovacuum is doing (and if it doesn't, let's fix it).
I think that is the best solution to the monitoring
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Any chance we can make this change before release? I think it's
very important to be able to look through the logs and *know*
that you tables are getting vacuumed or
Larry Rosenman wrote:
Alvaro Herrera wrote:
Alvaro Herrera wrote:
Matthew T. O'Connor wrote:
Bruce Momjian wrote:
Matthew T. O'Connor wrote:
Any chance we can make this change before release? I think it's
very important to be able to look through the logs and *know*
that you
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Agreed. I just IM'ed Alvaro and he says pg_stat_activity should now
show exactly what autovacuum is doing (and if it doesn't, let's fix it).
I think that is the best solution to the monitoring problem, rather than
throwing lines in
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
How do you figure that? The point of logging what's done is so that you
can find out what autovac has been doing, not what it's doing right now.
I don't think the server logs is the place to record history autovacuum
activity. I am
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
How do you figure that? The point of logging what's done is so that you
can find out what autovac has been doing, not what it's doing right now.
I don't think the server logs is the place to record history
Bruce Momjian wrote:
It is by default for unusual activity. It can be for normal activity
using the proper GUC settings, but we don't have a way to control
that just for autovacuum yet, and given what we have in 8.2, I don't
see a need to add more until users say they need more.
Right, the
68 matches
Mail list logo
