Simon Riggs wrote:
> On Fri, 2006-04-28 at 22:38 +0200, Martijn van Oosterhout wrote:
>> On Fri, Apr 28, 2006 at 03:18:56PM -0500, Larry Rosenman wrote:
Martijn van Oosterhout writes:
> You know, rather than adding new columns to pg_class, why not
> extend the stats collector to colle
On Fri, 2006-04-28 at 22:38 +0200, Martijn van Oosterhout wrote:
> On Fri, Apr 28, 2006 at 03:18:56PM -0500, Larry Rosenman wrote:
> > > Martijn van Oosterhout writes:
> > >> You know, rather than adding new columns to pg_class, why not extend
> > >> the stats collector to collect this information
Larry Rosenman wrote:
> Jim C. Nasby wrote:
>> On Mon, May 01, 2006 at 12:28:21PM -0500, Larry Rosenman wrote:
>>> Since both vacuum and autovacuum will be cutting stats records, do
>>> we want to just have the autovacuum
>>> stats record have the fact that it was autovacuum that did the
>>> vacuum
Jim C. Nasby wrote:
> On Mon, May 01, 2006 at 12:28:21PM -0500, Larry Rosenman wrote:
>> Since both vacuum and autovacuum will be cutting stats records, do we
>> want to just have the autovacuum
>> stats record have the fact that it was autovacuum that did the
>> vacuum?
>>
>> Or, is there a way
On Mon, May 01, 2006 at 12:28:21PM -0500, Larry Rosenman wrote:
> Since both vacuum and autovacuum will be cutting stats records, do we
> want to just have the autovacuum
> stats record have the fact that it was autovacuum that did the vacuum?
>
> Or, is there a way when vacuum is run by autovacuu
On Sat, Apr 29, 2006 at 10:05:51AM -0700, Mark Dilger wrote:
> Should we make the whole postgres logging system configurable, similar to
> log4j
> (or log4perl) rather than special-casing the autovacuum logs? Do we want to
> see
> options added piecemeal to the conf file such as "autovacuum_mess
On Thu, Apr 27, 2006 at 08:12:23PM +, Chris Browne wrote:
> Having some ability to collect statistics about "we recovered 42 pages
> from table foo at 12:45" would seem useful both from an immediate
> temporal perspective where it could suggest whether specific tables
> were being vacuumed too
Martijn van Oosterhout wrote:
> On Fri, Apr 28, 2006 at 04:08:41PM -0400, Robert Treat wrote:
>> The first is to add a column(s) to pg_class to hold last
>> vaccum/analyze time
>> for each table. The upsides would be that this puts the information
>> in a readily accessable place that can be view
Should we make the whole postgres logging system configurable, similar to log4j
(or log4perl) rather than special-casing the autovacuum logs? Do we want to see
options added piecemeal to the conf file such as "autovacuum_messages=silent"?
mark
---(end of broadcast)---
Martijn van Oosterhout wrote:
> On Fri, Apr 28, 2006 at 03:18:56PM -0500, Larry Rosenman wrote:
> > > Martijn van Oosterhout writes:
> > >> You know, rather than adding new columns to pg_class, why not extend
> > >> the stats collector to collect this information.
> >
> > That sounds doable. And
Martijn van Oosterhout wrote:
> On Fri, Apr 28, 2006 at 03:18:56PM -0500, Larry Rosenman wrote:
>>> Martijn van Oosterhout writes:
You know, rather than adding new columns to pg_class, why not
extend the stats collector to collect this information.
>>
>> That sounds doable. And a lot l
On Fri, Apr 28, 2006 at 03:18:56PM -0500, Larry Rosenman wrote:
> > Martijn van Oosterhout writes:
> >> You know, rather than adding new columns to pg_class, why not extend
> >> the stats collector to collect this information.
>
> That sounds doable. And a lot less scary for me (as a relative
>
Tom Lane wrote:
> Martijn van Oosterhout writes:
>> You know, rather than adding new columns to pg_class, why not extend
>> the stats collector to collect this information.
>
> +1
>
> regards, tom lane
That sounds doable. And a lot less scary for me (as a relative noobie)
Martijn van Oosterhout writes:
> You know, rather than adding new columns to pg_class, why not extend
> the stats collector to collect this information.
+1
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched
Robert Treat <[EMAIL PROTECTED]> writes:
> The first is to add a column(s) to pg_class to hold last vaccum/analyze time
> for each table.
I really don't want us to do that. relpages/reltuples are already an
ugly wart. The fundamental problem with this (or indeed any of the
various proposals for
On Fri, Apr 28, 2006 at 04:08:41PM -0400, Robert Treat wrote:
> The first is to add a column(s) to pg_class to hold last vaccum/analyze time
> for each table. The upsides would be that this puts the information in a
> readily accessable place that can be viewed from third party tools and
> quer
Robert Treat wrote:
> On Friday 28 April 2006 12:09, Larry Rosenman wrote:
>> Larry Rosenman wrote:
>>> Simon Riggs wrote:
On Thu, 2006-04-27 at 14:53 -0400, Tom Lane wrote:
> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
>> I'd like to see a more concrete definition of what we
>> w
On Friday 28 April 2006 12:09, Larry Rosenman wrote:
> Larry Rosenman wrote:
> > Simon Riggs wrote:
> >> On Thu, 2006-04-27 at 14:53 -0400, Tom Lane wrote:
> >>> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
> I'd like to see a more concrete definition of what we
> want Autovacuum to outpu
Larry Rosenman wrote:
> Simon Riggs wrote:
>> On Thu, 2006-04-27 at 14:53 -0400, Tom Lane wrote:
>>> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
I'd like to see a more concrete definition of what we
want Autovacuum to output and at what levels.
>>>
>>> autovacuum_verbosity
>>
>> Should
I suggest that maybe the cleanest solution is to not use log level at
all for this, but to invent a separate "autovacuum_verbosity" setting
that controls how many messages autovac tries to log, using the above
scale. Anything it does try to log can just come out at LOG message
setting.
+1
---
Those messages were at LOG level because otherwise it's difficult to be
sure from the log that autovac is running at all.
OK, so what do we want to do? Clearly outputing something everytime
pg_autovacuum touches a database isn't ideal. By default, the server
logs should show significant events
Simon Riggs wrote:
> On Thu, 2006-04-27 at 14:53 -0400, Tom Lane wrote:
>> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
>>> I'd like to see a more concrete definition of what we
>>> want Autovacuum to output and at what levels.
>>
>> autovacuum_verbosity
>
> Should we call it autovacuum_messages?
On Thu, 2006-04-27 at 14:53 -0400, Tom Lane wrote:
> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
> > I'd like to see a more concrete definition of what we
> > want Autovacuum to output and at what levels.
>
> autovacuum_verbosity
Should we call it autovacuum_messages?
In current usage...
_ve
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
>> Also it'd be nice to have it a (4th?) level which would show the
>> results of the equations being applied.
>
> That I think would fall more naturally into the category of debug
> support --- I'm happy if we just emit that at DEBUG1 a
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Also it'd be nice to have it a (4th?) level which would show the results
> of the equations being applied.
That I think would fall more naturally into the category of debug
support --- I'm happy if we just emit that at DEBUG1 and let people
select it wi
Larry Rosenman wrote:
> Tom Lane wrote:
> > Chris Browne <[EMAIL PROTECTED]> writes:
> >> At "level 2," it seems to me that it would be quite useful to have
> >> some way of getting at the verbose output of VACUUM.
> >
> > I think you can do that now, if you set min_log_level to INFO.
> > However
Tom Lane wrote:
> Chris Browne <[EMAIL PROTECTED]> writes:
>> At "level 2," it seems to me that it would be quite useful to have
>> some way of getting at the verbose output of VACUUM.
>
> I think you can do that now, if you set min_log_level to INFO.
> However, it might be cleaner if we allowed
Chris Browne <[EMAIL PROTECTED]> writes:
> At "level 2," it seems to me that it would be quite useful to have
> some way of getting at the verbose output of VACUUM.
I think you can do that now, if you set min_log_level to INFO. However,
it might be cleaner if we allowed a "level 3" that made all
Bruce Momjian wrote:
> Uh, while you are at it, the background writer and checkpoint
> operations need similar treatment. :-)
>
Sure.
I'm willing to look at and work it out, if no one else is currently
working on it.
LER
>
---
Uh, while you are at it, the background writer and checkpoint operations
need similar treatment. :-)
---
Larry Rosenman wrote:
> Tom Lane wrote:
> > "Larry Rosenman" <[EMAIL PROTECTED]> writes:
> >> I'd like to see a more c
[EMAIL PROTECTED] (Tom Lane) writes:
> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
>> I'd like to see a more concrete definition of what we
>> want Autovacuum to output and at what levels.
>
> I would argue that what people typically want is
>
> (0) nothing
>
> (1) per-datab
Tom Lane wrote:
> "Larry Rosenman" <[EMAIL PROTECTED]> writes:
>> I'd like to see a more concrete definition of what we
>> want Autovacuum to output and at what levels.
>
> I would argue that what people typically want is
>
> (0) nothing
>
> (1) per-database log messages
>
>
On 4/27/06, Tom Lane <[EMAIL PROTECTED]> wrote:
> I suggest that maybe the cleanest solution is to not use log level at
> all for this, but to invent a separate "autovacuum_verbosity" setting
> that controls how many messages autovac tries to log, using the above
> scale. Anything it does try to l
"Larry Rosenman" <[EMAIL PROTECTED]> writes:
> I'd like to see a more concrete definition of what we
> want Autovacuum to output and at what levels.
I would argue that what people typically want is
(0) nothing
(1) per-database log messages
or
(2) per-table
Bruce Momjian wrote:
> Matthew T. O'Connor wrote:
>> I think there are two things people typically want to know from the
>> logs: 1) Is autovacuum running 2) Did autovacuum take action (issue
>> a VACUUM or ANALYZE)
>>
>> I don't think we need mention the name of each and every database we
>> tou
Matthew T. O'Connor wrote:
> I think there are two things people typically want to know from the logs:
> 1) Is autovacuum running
> 2) Did autovacuum take action (issue a VACUUM or ANALYZE)
>
> I don't think we need mention the name of each and every database we
> touch, we can, but it should be
I think there are two things people typically want to know from the logs:
1) Is autovacuum running
2) Did autovacuum take action (issue a VACUUM or ANALYZE)
I don't think we need mention the name of each and every database we
touch, we can, but it should be at a lower level like DEBUG1 or someth
Tom Lane wrote:
> [EMAIL PROTECTED] (Bruce Momjian) writes:
> > Change log message about vacuuming database name from LOG to DEBUG1.
> > Prevents duplicate meaningless log messsages.
>
> Could we have some discussion about this sort of thing, rather than
> unilateral actions?
>
> Those messages w
38 matches
Mail list logo
