[ 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
---------------------------(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
