Lists: | pgsql-hackers |
---|
From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | log_autovacuum |
Date: | 2007-08-03 15:27:20 |
Message-ID: | 87vebwabaf.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Could I suggest renaming log_autovacuum to log_autovacuum_min_duration?
I found it confusing to when setting it to 0 *enabled* logging so I imagine
others will be as well. Also it seems we may want to have other messages
logged from autovacuum so it would be better to leave room for other
log_autovacuum_* parameters and possibly a master "log_autovacuum" parameter.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Gregory Stark <stark(at)enterprisedb(dot)com> |
Cc: | PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: log_autovacuum |
Date: | 2007-08-03 16:03:51 |
Message-ID: | 20070803160351.GA9478@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Gregory Stark wrote:
>
> Could I suggest renaming log_autovacuum to log_autovacuum_min_duration?
Sure, whatever makes the most sense. In fact min_duration would be more
consistent.
--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
"El día que dejes de cambiar dejarás de vivir"
From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Gregory Stark <stark(at)enterprisedb(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: log_autovacuum |
Date: | 2007-08-03 16:38:46 |
Message-ID: | 17277.1186159126@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Gregory Stark wrote:
>> Could I suggest renaming log_autovacuum to log_autovacuum_min_duration?
> Sure, whatever makes the most sense. In fact min_duration would be more
> consistent.
I'm not sure I believe Greg's argument about needing more autovac
logging parameters, but since this one acts just like
log_min_duration_statement, I concur with renaming it.
regards, tom lane
From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: log_autovacuum |
Date: | 2007-08-03 17:56:59 |
Message-ID: | 87sl70lcwk.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
Actually, we happen to be running into a situation here where we need more
logging. We need to understand why autovacuum isn't considering logging this
table:
relid | schemaname | relname | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup | n_dead_tup | last_vacuum | last_autovacuum | last_analyze | last_autoanalyze
-------+------------+------------+----------+--------------+----------+---------------+-----------+-----------+-----------+------------+------------+-------------+-------------------------------+--------------+-------------------------------
16436 | public | stock | 0 | 0 | 45929274 | 45928278 | 0 | 12116286 | 0 | 25036190 | 12723033 | | | | 2007-08-01 17:24:30.796874-07
It looks like there are some DEBUG3 messages which would be useful but I don't
know of any convenient way to change the log level in autovacuum workers.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: log_autovacuum |
Date: | 2007-08-03 19:59:15 |
Message-ID: | 1186171155.4136.3.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On Fri, 2007-08-03 at 12:38 -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> > Gregory Stark wrote:
> >> Could I suggest renaming log_autovacuum to log_autovacuum_min_duration?
>
> > Sure, whatever makes the most sense. In fact min_duration would be more
> > consistent.
>
> I'm not sure I believe Greg's argument about needing more autovac
> logging parameters, but since this one acts just like
> log_min_duration_statement, I concur with renaming it.
log_min_duration_autovacuum
makes the most sense in comparison, IMHO.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
---|---|
To: | "Gregory Stark" <stark(at)enterprisedb(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: log_autovacuum |
Date: | 2007-08-03 20:33:03 |
Message-ID: | 1186173183.4136.22.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On Fri, 2007-08-03 at 18:56 +0100, Gregory Stark wrote:
> Actually, we happen to be running into a situation here where we need more
> logging. We need to understand why autovacuum isn't considering logging this
> table:
>
> relid | schemaname | relname | seq_scan | seq_tup_read | idx_scan | idx_tup_fetch | n_tup_ins | n_tup_upd | n_tup_del | n_live_tup | n_dead_tup | last_vacuum | last_autovacuum | last_analyze | last_autoanalyze
> -------+------------+------------+----------+--------------+----------+---------------+-----------+-----------+-----------+------------+------------+-------------+-------------------------------+--------------+-------------------------------
> 16436 | public | stock | 0 | 0 | 45929274 | 45928278 | 0 | 12116286 | 0 | 25036190 | 12723033 | | | | 2007-08-01 17:24:30.796874-07
>
> It looks like there are some DEBUG3 messages which would be useful but I don't
> know of any convenient way to change the log level in autovacuum workers.
It also appears that only a single autovacuum daemon active at any one
time, which is also weird when we are supposed to have 3.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
From: | Michael Glaesemann <grzm(at)seespotcode(dot)net> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: log_autovacuum |
Date: | 2007-08-03 20:44:07 |
Message-ID: | 03ABF927-E42D-45A2-B64E-FCC77543E816@seespotcode.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
On Aug 3, 2007, at 14:59 , Simon Riggs wrote:
> On Fri, 2007-08-03 at 12:38 -0400, Tom Lane wrote:
>> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>>> Gregory Stark wrote:
>>>> Could I suggest renaming log_autovacuum to
>>>> log_autovacuum_min_duration?
>>
>>> Sure, whatever makes the most sense. In fact min_duration would
>>> be more
>>> consistent.
>>
>> I'm not sure I believe Greg's argument about needing more autovac
>> logging parameters, but since this one acts just like
>> log_min_duration_statement, I concur with renaming it.
> log_min_duration_autovacuum
>
> makes the most sense in comparison, IMHO.
True, but the log_min_duration_statement is kind of poorly named (as
is log_min_error_statement). log_statement is the overall concept,
min_duration and min_error further specialize the concept.
log_statement_min_duration and log_statement_min_error would have
been better, IMO. Question is whether it's better to move forward
with consistent naming or improve naming when the chance arises.
Michael Glaesemann
grzm seespotcode net