Re: GUC variable renaming, redux

[ just when you thought it was safe to go back in the water ]

In threads starting here and here:
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00874.php
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00043.php
I believe we had reached consensus on the following points:

* log_autovacuum should be renamed log_autovacuum_min_duration
to better reflect its meaning.
* stats_start_collector should go away; we should just always start the
collector process.
* stats_block_level and stats_row_level should be merged into a
single variable, here referred to as $merged_var, which would
control all reports sent to the stats collector process.

What we lack is consensus on what the name of $merged_var should be,
and whether we should rename any related variables while at it.
I'm sending out this message in hopes of pushing that forward to
a conclusion.

First off: arguments from backwards compatibility, while not to be
disregarded, seem pretty weak here. The variables we are thinking of
changing hardly seem likely to be set anywhere but postgresql.conf, and
we have always felt free to whack around the contents of postgresql.conf
from release to release. Furthermore the already-agreed-to changes
would break any backwards compatibility in this area. I think
compatibility is a reasonable argument for not indulging in wholesale
renaming of existing variables, but it should not stop us from
considering all the stats-related variables at this time.

After the agreed-on changes, "all the stats-related variables" will
actually boil down to these:

stats_command_string
$merged_var
stats_reset_on_server_start

There was some argument that we need to keep all these variables
similarly named; though that argument seems a bit weak seeing that
stats_command_string controls a feature which has absolutely nothing
to do with the other two variables, either from an implementation
standpoint or as to user-visible behavior. Another problem with
stats_command_string is that it's gotten to be an extremely bad
description of the information actually made available. (The view
it feeds, pg_stat_activity, is much more sanely named.)

Another consideration that was suggested repeatedly was that it's
good to emphasize a verb when naming one of these variables.

I found the following suggestions in the thread:

For stats_command_string:

collect_query_string
stats_query_strings
track_activities
track_activity

For $merged_var:

collect_event_stats
collect_stats
stats_collection
stats_count_events
stats_counters
track_events
track_stats

There wasn't any discussion of renaming stats_reset_on_server_start,
though logical consistency would seem to require this if we choose
a name not starting with stats_ for $merged_var.

Personally I would favor

track_activities
track_counts
reset_counts_on_server_start

if we go with the "emphasize the verb" idea, or

stats_activities
stats_counts
stats_reset_on_server_start

if we want to stick with "stats" as the key word. Or maybe,
if we like both concepts,

stats_track_activities
stats_track_counts
stats_reset_on_server_start

Comments? I hope this doesn't turn into another long-drawn-out thread,
but we need to make a decision.

regards, tom lane

I wrote:
> There wasn't any discussion of renaming stats_reset_on_server_start,
> though logical consistency would seem to require this if we choose
> a name not starting with stats_ for $merged_var.

Actually ... does stats_reset_on_server_start have a reason to live
at all? It hardly seems like a behavior that ought to occur on a
routine basis, and anyone who really wants it can remove the pgstats
file manually before starting the postmaster.

Or maybe the problem with it is that it should only zero the event
counters (n_tuples_inserted) and not the persistent state
(n_live_tuples, last_vacuum_time, etc). pgstats started out as
basically just event counters, but we've allowed a lot of other stuff
to get in there over time. If we define the variable that way, though,
it really needs a name change.

regards, tom lane

Tom Lane wrote:
> I wrote:
> > There wasn't any discussion of renaming stats_reset_on_server_start,
> > though logical consistency would seem to require this if we choose
> > a name not starting with stats_ for $merged_var.
>
> Actually ... does stats_reset_on_server_start have a reason to live
> at all? It hardly seems like a behavior that ought to occur on a
> routine basis, and anyone who really wants it can remove the pgstats
> file manually before starting the postmaster.

We also have a stats reset after recovery, and a function to reset it at
the user's whim, so I agree that there doesn't seem to be any reason to
keep it. Neither of these existed when stats_reset_on_server_start was
implemented, IIRC.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Am Sonntag, 23. September 2007 schrieb Tom Lane:
> Actually ... does stats_reset_on_server_start have a reason to live
> at all?

Kill it. It never made much sense to me anyway.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane wrote:
>> Actually ... does stats_reset_on_server_start have a reason to live
>> at all?

> We also have a stats reset after recovery, and a function to reset it at
> the user's whim, so I agree that there doesn't seem to be any reason to
> keep it. Neither of these existed when stats_reset_on_server_start was
> implemented, IIRC.

Good point about the function --- that seems more than sufficient for
any possible usefulness of a reset behavior.

So if stats_reset_on_server_start goes away, then we have only two
variable names to worry about, and they control separate behaviors
so there seems no compelling reason to name them alike. That leaves
me favoring the approach of calling them

track_activities
track_counts

Rather than calling for more discussion, maybe I should just say
"has anyone got a strong objection to these names"?

regards, tom lane

On Sun, 2007-09-23 at 12:51 -0400, Tom Lane wrote:

> Personally I would favor
>
> track_activities
> track_counts

I would personally prefer the verb "monitor" rather than track. The
chapter in the docs is already called "Monitoring Database Activity".
Sysadmins know their job is about monitoring; I never heard anyone say
"how do we track the database?", nor are there other products that refer
to themselves as "tracking tools".

There has always been a confusion between different kinds of stats, so a
name change is good.

"_counts" sounds like it might have something to do with Select Count(*)
and I can see everybody getting confused between counts and activities.

Can we have these two, please?

monitor_activity = on | off
monitor_command_strings = on | off

[Activities is correct English, though not common usage, as is shown by
the chapter heading in the docs. Most computer people know that an
Activity Monitor will monitor more than one thing at a time and that if
"there has been some activity" then that might mean one or more events
have occurred. It's also easier for non-English speakers if we avoid the
plural.]

> reset_counts_on_server_start
Yes, this can go.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

Am Montag, 24. September 2007 schrieb Simon Riggs:
> I would personally prefer the verb "monitor" rather than track. The
> chapter in the docs is already called "Monitoring Database Activity".

What the database system does is tracking. Then you use an administrator or
Nagios to monitor the results of the tracking.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Mon, 2007-09-24 at 12:51 +0200, Peter Eisentraut wrote:
> Am Montag, 24. September 2007 schrieb Simon Riggs:
> > I would personally prefer the verb "monitor" rather than track. The
> > chapter in the docs is already called "Monitoring Database Activity".
>
> What the database system does is tracking. Then you use an administrator or
> Nagios to monitor the results of the tracking.

www.nagios.org "Nagios® is an Open Source host, service and network
monitoring program". Not a single word about tracking anywhere.

PostgreSQL doesn't use the word "tracking" anywhere in the section on
stats. If it was natural to do so, we would have used that word already.
We "track dependencies" but thats it.

http://encarta.msn.com/dictionary_/monitor.html
"computer program: a computer program that observes and controls other
programs in a system"

http://dictionary.reference.com/browse/monitor
Computers.
c.
a group of systems used to measure
the performance of a computer
system.

"Track" doesn't have any similar meaning.

I'm sorry to raise this now. The earlier proposal for "track_" wasn't
supported by anyone that I can see, even though we decided to change the
way the stats parameters were arranged on those earlier threads.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> I'm sorry to raise this now. The earlier proposal for "track_" wasn't
> supported by anyone that I can see, even though we decided to change the
> way the stats parameters were arranged on those earlier threads.

Well, there was at least one other person who liked "track" at the time:
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00996.php
which gave it about as much support as any other alternative that was
mentioned :-(

While I don't have any strong objection to changing "track" to "monitor",
I'm not enthused by the other parts of your proposal. In particular
I do object to using "activity" for the variable that is specifically
*not* associated with feeding pg_stat_activity.

regards, tom lane

On Mon, 2007-09-24 at 12:50 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > I'm sorry to raise this now. The earlier proposal for "track_" wasn't
> > supported by anyone that I can see, even though we decided to change the
> > way the stats parameters were arranged on those earlier threads.
>
> Well, there was at least one other person who liked "track" at the time:
> http://archives.postgresql.org/pgsql-hackers/2007-07/msg00996.php
> which gave it about as much support as any other alternative that was
> mentioned :-(
>
> While I don't have any strong objection to changing "track" to "monitor",

> I'm not enthused by the other parts of your proposal.

> In particular
> I do object to using "activity" for the variable that is specifically
> *not* associated with feeding pg_stat_activity.

Thats a good point, that would be very confusing.
So it should be stats_command_string --> monitor_activity

...and the other one would be monitor_counts? OK, that fits for me.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> So it should be stats_command_string --> monitor_activity
> ...and the other one would be monitor_counts? OK, that fits for me.

Are we worried about having them both singular or both plural?
I seem to recall that point coming up in the prior thread.

regards, tom lane

On Mon, 2007-09-24 at 13:09 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > So it should be stats_command_string --> monitor_activity
> > ...and the other one would be monitor_counts? OK, that fits for me.
>
> Are we worried about having them both singular or both plural?
> I seem to recall that point coming up in the prior thread.

Not really, common usage rules.

monitor_activity
monitor_counts

sounds correct to me.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Simon Riggs wrote:
> On Mon, 2007-09-24 at 13:09 -0400, Tom Lane wrote:
>> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
>>> So it should be stats_command_string --> monitor_activity
>>> ...and the other one would be monitor_counts? OK, that fits for me.
>> Are we worried about having them both singular or both plural?
>> I seem to recall that point coming up in the prior thread.
>
> Not really, common usage rules.
>
> monitor_activity
> monitor_counts
>
> sounds correct to me.

IMO, monitor_ seems weird versus track_. To me monitor implies actions
to be taken when thresholds are met. PostgreSQL doesn't do that.
PostgreSQL tracks/stores information for application to monitor or
interact with and those application may doing something based on the
tracked information.

However, both are better than what we have.

SIncerely,

Joshua D. Drake

- --

=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG9/ocATb/zqfZUUQRArJFAJ4w1gIUeuKPUT4RsEvTME8f/MtBDQCdGHDn
AZpghGP4tL52h/xgqF2Q4zM=
=ELJk
-----END PGP SIGNATURE-----

Am Montag, 24. September 2007 schrieb Joshua D. Drake:
> IMO, monitor_ seems weird versus track_. To me monitor implies actions
> to be taken when thresholds are met. PostgreSQL doesn't do that.
> PostgreSQL tracks/stores information for application to monitor or
> interact with and those application may doing something based on the
> tracked information.

Yes, that is the point I was trying to make.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

On Mon, 2007-09-24 at 10:55 -0700, Joshua D. Drake wrote:
> IMO, monitor_ seems weird versus track_. To me monitor implies actions
> to be taken when thresholds are met. PostgreSQL doesn't do that.
> PostgreSQL tracks/stores information for application to monitor or
> interact with and those application may doing something based on the
> tracked information.

Not that my opinion would count too much on hackers, but "track" sounds
better to me too, seems more to the point, not to mention it's shorter
too.

+1 "track"

Cheers,
Csaba.

On Tue, 2007-09-25 at 10:15 +0200, Csaba Nagy wrote:
> On Mon, 2007-09-24 at 10:55 -0700, Joshua D. Drake wrote:
> > IMO, monitor_ seems weird versus track_. To me monitor implies actions
> > to be taken when thresholds are met. PostgreSQL doesn't do that.
> > PostgreSQL tracks/stores information for application to monitor or
> > interact with and those application may doing something based on the
> > tracked information.
>
> Not that my opinion would count too much on hackers, but "track" sounds
> better to me too, seems more to the point, not to mention it's shorter
> too.
>
> +1 "track"

track_* wins the vote, so no change to committed code.

It's much easier when there's a clear majority, no need for further
debate that way.

--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com