From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Lee <tom(at)vector-seven(dot)com> |
Cc: | David Miller <miller392(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Backend Stats Enhancement Request |
Date: | 2008-06-20 14:49:49 |
Message-ID: | 17540.1213973389@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Lee <tom(at)vector-seven(dot)com> writes:
> How does this sound:
> * A new GUC variable -- "activity_message_size" -- will be introduced
Well, "message" doesn't seem quite le mot juste to me for a column that
is displaying a SQL command. Usually we'd use "statement", "command",
or "query" to refer to one of those things. Since the relevant column
of pg_stat_activity is already named "current_query", perhaps the
best choice is "activity_query_size". Or "activity_query_length"?
Another consideration is that it might be a good idea to name it to
be obviously related to the controlling "track_activities" boolean.
That would lead to "track_activity_query_size", or
"track_activity_max_length", or some such.
> * Minimum value of PGBE_DEFAULT_ACTIVITY_SIZE, maximum value of INT_MAX?
I was thinking about a range of 100 to 100K or thereabouts. INT_MAX
is just silly...
> I'm struggling a little to come up with a decent description of the GUC
> variable -- something along the lines of "Sets the maximum length of
> backend status messages". Any suggestions?
Be specific:
"Sets the maximum length of pg_stat_activity.current_query."
> Also: how should we allocate the memory for PgBackendStatus.st_activity?
> I'm guessing it's going to be necessary to keep this in shmem ...
Yup. Look at existing variable-size shmem allocations.
max_prepared_transactions might be a good reference, since it's not
used in very many places.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Decibel! | 2008-06-20 16:12:38 | Re: Backend Stats Enhancement Request |
Previous Message | Tom Lane | 2008-06-20 14:37:33 | Re: Not valid dump [8.2.9, 8.3.1] |