I applied this patch some hours ago but I haven't gotten the
pgsql-committers mail and I don't see it in the archives either. Here
is the evidence:
http://developer.postgresql.org/cvsweb.cgi/pgsql/doc/src/sgml/config.sgml
Is there a problem with pgsql-committers again? Attached is the patch I
a
On Tue, 2007-04-17 at 21:45 -0400, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
>
> > Seems fair. Updated patch attached.
> >
> > If there are no further comments, I'll add some docs and apply it later.
>
> If autovacuum_vacuum_cost_delay is set to 20, my pitiful desktop system
> takes 8.4 sec
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I also think we should remove these DEBUG messages, that are now
> useless:
> DEBUG: autovac: will ANALYZE bar
+1, those were just ad-hoc.
regards, tom lane
---(end of broadcast)---
Alvaro Herrera wrote:
> Seems fair. Updated patch attached.
>
> If there are no further comments, I'll add some docs and apply it later.
If autovacuum_vacuum_cost_delay is set to 20, my pitiful desktop system
takes 8.4 seconds to analyze a 8000 page table:
DEBUG: "bar": scanned 3000 of 8811 p
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Alvaro Herrera wrote:
> >> Tom Lane wrote:
> >>> BTW, shouldn't the log entry distinguish whether this was VACUUM,
> >>> ANALYZE, or both?
> >>
> >> We don't actually log anything for ANALYZE (the logging code is in
> >> lazy_vacuum_
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Alvaro Herrera wrote:
>> Tom Lane wrote:
>>> BTW, shouldn't the log entry distinguish whether this was VACUUM,
>>> ANALYZE, or both?
>>
>> We don't actually log anything for ANALYZE (the logging code is in
>> lazy_vacuum_rel).
>>
>> Maybe it should be
Alvaro Herrera wrote:
> Tom Lane wrote:
> > BTW, shouldn't the log entry distinguish whether this was VACUUM,
> > ANALYZE, or both?
>
> We don't actually log anything for ANALYZE (the logging code is in
> lazy_vacuum_rel).
>
> Maybe it should be in autovacuum.c.
The only problem with this is tha
On Tue, 2007-04-17 at 16:41 -0400, Alvaro Herrera wrote:
> Tom Lane wrote:
> > BTW, shouldn't the log entry distinguish whether this was VACUUM,
> > ANALYZE, or both?
>
> We don't actually log anything for ANALYZE (the logging code is in
> lazy_vacuum_rel).
When ANALYZE starts taking some time, w
Tom Lane wrote:
> BTW, shouldn't the log entry distinguish whether this was VACUUM,
> ANALYZE, or both?
We don't actually log anything for ANALYZE (the logging code is in
lazy_vacuum_rel).
Maybe it should be in autovacuum.c.
--
Alvaro Herrerahttp://www.CommandPro
BTW, shouldn't the log entry distinguish whether this was VACUUM,
ANALYZE, or both?
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail comma
In response to Alvaro Herrera <[EMAIL PROTECTED]>:
> Simon Riggs wrote:
> > On Tue, 2007-04-17 at 14:06 -0400, Alvaro Herrera wrote:
>
> > > I've tinkered with this patch a bit. Sample output:
> > >
> > > LOG: automatic vacuum of table "alvherre.public.foo": index scans: 0
> > > pages:
On Tue, 2007-04-17 at 14:45 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On Tue, 2007-04-17 at 14:06 -0400, Alvaro Herrera wrote:
>
> > > I've tinkered with this patch a bit. Sample output:
> > >
> > > LOG: automatic vacuum of table "alvherre.public.foo": index scans: 0
> > > p
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Simon Riggs wrote:
>> Perhaps we need this as an integer, so we can log all vacuums that last
>> for longer in seconds than the setting, 0 logs all. That would
>> significantly reduce the volume if we set it to 5, say. That way you
>> would get your read
Simon Riggs wrote:
> On Tue, 2007-04-17 at 14:06 -0400, Alvaro Herrera wrote:
> > I've tinkered with this patch a bit. Sample output:
> >
> > LOG: automatic vacuum of table "alvherre.public.foo": index scans: 0
> > pages: removed 0, 11226 remain
> > tuples: 1300683 removed, 1096
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I've tinkered with this patch a bit. Sample output:
>
> > LOG: automatic vacuum of table "alvherre.public.foo": index scans: 0
> > pages: removed 0, 11226 remain
> > tuples: 1300683 removed, 1096236 remain
> >
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> I've tinkered with this patch a bit. Sample output:
> LOG: automatic vacuum of table "alvherre.public.foo": index scans: 0
> pages: removed 0, 11226 remain
> tuples: 1300683 removed, 1096236 remain
> system usage: CPU 0.29s/0.3
On Tue, 2007-04-17 at 14:06 -0400, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > On Thu, 2007-03-08 at 14:53 -0300, Alvaro Herrera wrote:
> > > Maybe something like this is better:
> > >
> > > LOG: index passes: 1 pages: removed 0, 197 remain tuples: removed 7199,
> > > 2338 remain CPU usage
Simon Riggs wrote:
> On Thu, 2007-03-08 at 14:53 -0300, Alvaro Herrera wrote:
> > Maybe something like this is better:
> >
> > LOG: index passes: 1 pages: removed 0, 197 remain tuples: removed 7199,
> > 2338 remain CPU usage: whatever
> > CONTEXT: Automatic vacuuming of table "database.public
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Si
Hi,
On 3/9/07, Simon Riggs <[EMAIL PROTECTED]> wrote:
On Thu, 2007-03-08 at 14:53 -0300, Alvaro Herrera wrote:
> Maybe something like this is better:
>
> LOG: index passes: 1 pages: removed 0, 197 remain tuples: removed
7199, 2338 remain CPU usage: whatever
> CONTEXT: Automatic vacuuming of
On Thu, 2007-03-08 at 14:53 -0300, Alvaro Herrera wrote:
> Maybe something like this is better:
>
> LOG: index passes: 1 pages: removed 0, 197 remain tuples: removed 7199,
> 2338 remain CPU usage: whatever
> CONTEXT: Automatic vacuuming of table "database.public.w"
Yours is better.
I've imp
Darcy Buskermolen wrote:
> On March 8, 2007 09:53 am, Alvaro Herrera wrote:
> > Keep in mind that it's going to be translated, so it's not useful for
> > machine parsing anyway.
>
> This goes back to the request for vacuum loging to a table..
That's right, but please let's have at least *someth
On March 8, 2007 09:53 am, Alvaro Herrera wrote:
> Simon Riggs wrote:
> > log_autovacuum = on produces a single line of output from autovacuum,
> > with additional useful stats. Patch is proving useful in performance
> > testing. Not sure what is intended on logging for 8.3
> >
> > LOG: autova
Simon Riggs wrote:
> log_autovacuum = on produces a single line of output from autovacuum,
> with additional useful stats. Patch is proving useful in performance
> testing. Not sure what is intended on logging for 8.3
>
> LOG: autovac "public.w" scans:1 pages:197(-0) tuples:2338(-7199) CPU
>
On Thu, 2007-03-08 at 16:05 +, Simon Riggs wrote:
> LOG: autovac "public.w" scans:1 pages:197(-0) tuples:2338(-7199) CPU
> 0.00s/0.00u sec elapsed 0.39 sec
Seems like a pretty cryptic log format to me.
-Neil
---(end of broadcast)---
TIP 5: d
log_autovacuum = on produces a single line of output from autovacuum,
with additional useful stats. Patch is proving useful in performance
testing. Not sure what is intended on logging for 8.3
LOG: autovac "public.w" scans:1 pages:197(-0) tuples:2338(-7199) CPU
0.00s/0.00u sec elapsed 0.39 se
26 matches
Mail list logo
