Lists: | pgsql-hackers |
---|
From: | "Larry Rosenman" <lrosenman(at)pervasive(dot)com> |
---|---|
To: | "Larry Rosenman" <lrosenman(at)pervasive(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net>, "PostgreSQL-development" <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | Re: Logging pg_autovacuum |
Date: | 2006-04-28 16:09:40 |
Message-ID: | F6616E0E81AC0841B1F9DD252F7C4B55041A3F@ausmaildd.aus.pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Larry Rosenman wrote:
> Simon Riggs wrote:
>> On Thu, 2006-04-27 at 14:53 -0400, Tom Lane wrote:
>>> "Larry Rosenman" <lrosenman(at)pervasive(dot)com> 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...
>>
>> _verbosity controls how much information each message gives
>> _messages controls what types of messages are logged
>
> That probably works, but I'm not sure about the one to add the VERBOSE
> to the
> VACUUM commands autovacuum.c emits.
does the following options satisfy everyone:
autovacuum_messages=
none silent (nothing output at LOG level)
database we'd output a LOG message processing database <name>
table we'd output a LOG message for each table we actually vacuum /
analyze
verbose we'd add the verbose flag to each command
the lower levels would include the upper (I.E. verbose implies table +
database).
If this is acceptable, I'm going to start working on the code to
implement it.
LER
--
Larry Rosenman
Database Support Engineer
PERVASIVE SOFTWARE. INC.
12365B RIATA TRACE PKWY
3015
AUSTIN TX 78727-6531
Tel: 512.231.6173
Fax: 512.231.6597
Email: Larry(dot)Rosenman(at)pervasive(dot)com
Web: www.pervasive.com
From: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Cc: | "Larry Rosenman" <lrosenman(at)pervasive(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
Subject: | Re: Logging pg_autovacuum |
Date: | 2006-04-28 20:08:41 |
Message-ID: | 200604281608.41830.xzilla@users.sourceforge.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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" <lrosenman(at)pervasive(dot)com> 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...
> >>
> >> _verbosity controls how much information each message gives
> >> _messages controls what types of messages are logged
> >
> > That probably works, but I'm not sure about the one to add the VERBOSE
> > to the
> > VACUUM commands autovacuum.c emits.
>
> does the following options satisfy everyone:
>
> autovacuum_messages=
> none silent (nothing output at LOG level)
> database we'd output a LOG message processing database <name>
> table we'd output a LOG message for each table we actually vacuum /
> analyze
> verbose we'd add the verbose flag to each command
>
> the lower levels would include the upper (I.E. verbose implies table +
> database).
>
> If this is acceptable, I'm going to start working on the code to
> implement it.
>
This would certainly be an improvement, but in the intrest of full discussion,
I want to toss out a couple of ideas (they are only partially thought out,
but I think could be useful)
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
queried against for easier management along with accomplishing what the
current logging is giving you.
The second is to add a "verbosity level" to pg_autovacuum for each table, to
allow admins to configure specific tables for a more verbose logging. This
way if you have a perticular table that needs additional logging, this could
allow you to have only its vacuums emmitied at whichever log level seemed
appropriate.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Larry Rosenman <lrosenman(at)pervasive(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
Subject: | Re: Logging pg_autovacuum |
Date: | 2006-04-28 20:15:36 |
Message-ID: | 20060428201536.GE15566@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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
> queried against for easier management along with accomplishing what the
> current logging is giving you.
You know, rather than adding new columns to pg_class, why not extend
the stats collector to collect this information. This seems to fall
well within its mandate and it already has the necessary infrastructure
to store info like this. The people likely to want this sort of info
are likely to be running the stats collector anyway. The GUC then
becomes.
stats_autovacuum= on
No more fiddling with log levels or parsing log file, just:
select <the info you want> from pg_stats_autovacuum;
If this table is empty, it isn't running. How often do you want to know
if it was running 5 hours ago?
Thoughts?
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, "Larry Rosenman" <lrosenman(at)pervasive(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
Subject: | Re: Logging pg_autovacuum |
Date: | 2006-04-28 20:16:22 |
Message-ID: | 15756.1146255382@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> 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 "let's make vacuum store results someplace")
is that vacuum is supposed to *clean up* dead rows. Not make more.
We don't want a pass of autovacuum to leave pg_class in a desperately-
needs-vacuumed-again state.
> The second is to add a "verbosity level" to pg_autovacuum for each table, to
> allow admins to configure specific tables for a more verbose logging.
No fundamental objection, but I can't really see the need either.
regards, tom lane
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net>, pgsql-hackers(at)postgresql(dot)org, Larry Rosenman <lrosenman(at)pervasive(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Matthew T(dot) O'Connor" <matthew(at)zeut(dot)net> |
Subject: | Re: Logging pg_autovacuum |
Date: | 2006-04-28 20:18:15 |
Message-ID: | 15799.1146255495@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)org> 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
From: | Mark Dilger <pgsql(at)markdilger(dot)com> |
---|---|
To: | Larry Rosenman <lrosenman(at)pervasive(dot)com> |
Subject: | Re: Logging pg_autovacuum |
Date: | 2006-04-29 17:05:51 |
Message-ID: | 44539CEF.4040600@markdilger.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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
From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Mark Dilger <pgsql(at)markdilger(dot)com> |
Cc: | Larry Rosenman <lrosenman(at)pervasive(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Logging pg_autovacuum |
Date: | 2006-05-01 18:07:36 |
Message-ID: | 20060501180736.GC97354@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
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_messages=silent"?
This does sound like a better idea, especially since there's call for
improving bgwriter and stats collector logging as well.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461