Re: [HACKERS] GUC variable renaming, redux
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 ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] GUC variable renaming, redux
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/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] GUC variable renaming, redux
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. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] GUC variable renaming, redux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Riggs wrote: > On Mon, 2007-09-24 at 13:09 -0400, Tom Lane wrote: >> Simon Riggs <[EMAIL PROTECTED]> 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- ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] GUC variable renaming, redux
On Mon, 2007-09-24 at 13:09 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] GUC variable renaming, redux
Simon Riggs <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] GUC variable renaming, redux
On Mon, 2007-09-24 at 12:50 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] GUC variable renaming, redux
Simon Riggs <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] GUC variable renaming, redux
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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] GUC variable renaming, redux
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/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] GUC variable renaming, redux
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] GUC variable renaming, redux
Alvaro Herrera <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] GUC variable renaming, redux
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/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] GUC variable renaming, redux
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 Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] GUC variable renaming, redux
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org