Re: autovacuum "connections" are hidden - Mailing list pgsql-general

From Jim C. Nasby
Subject Re: autovacuum "connections" are hidden
Date
Msg-id 20060522212916.GV64371@pervasive.com
Whole thread Raw
In response to Re: autovacuum "connections" are hidden  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
Moving to -hackers

Does this still obey stats_command_string? I think it'd be very handy to
either have autovac always report what it's doing (ignoring
stats_command_string), or to provide it with it's own option for it. I
doubt this should pose a performance issue, since unless you have a
whole lot of small tables autovac shouldn't be issuing commands very
frequently.

On Thu, May 18, 2006 at 07:28:50PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > This seems to work for me.  I'd appreciate input, as I'm not sure how
> > would other archs (or even my own) cope with the zeroed client address
> > trick (note the memcmp ...)
>
> AFAICS that should work; I can't imagine all-zeroes being a valid client
> address.  I'd suggest commenting it as "process has no client" rather
> than "don't know".
>
> > (The actual activity reported is a bit bogus ... I'd appreciate
> > suggestions for better wording.  Do I waste cycles in obtaining the
> > relname?  My answer is yes.  What if there are multiple rels (a case
> > currently not exercised)?.  Should it explicitly say that it's
> > autovacuum?  My answer is no.)
>
> What I was expecting was to see one of
>
>     VACUUM
>     ANALYZE
>     VACUUM ANALYZE
>     VACUUM foo
>     ANALYZE foo
>     VACUUM ANALYZE foo
>
> ie exactly the command being executed if you were to type the manual
> equivalent.
>
> Since the multiple-rels case isn't used, there seems no need to debate
> how it ought to report...
>
> BTW, patches are probably off-topic for pgsql-general.
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq
>

--
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461

pgsql-general by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Contributing code
Next
From: "Jim C. Nasby"
Date:
Subject: Re: ALTER SEQUENCE