Обсуждение: 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 wouldcontrol 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_varstats_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@commandprompt.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@2ndquadrant.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@2ndquadrant.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@2ndquadrant.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@2ndquadrant.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@2ndquadrant.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-----
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.
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 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