Re: Backend Stats Enhancement Request - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Backend Stats Enhancement Request
Date
Msg-id 17540.1213973389@sss.pgh.pa.us
Whole thread Raw
In response to Re: Backend Stats Enhancement Request  (Thomas Lee <tom@vector-seven.com>)
Responses Re: Backend Stats Enhancement Request  (Decibel! <decibel@decibel.org>)
Re: Backend Stats Enhancement Request  (Robert Treat <xzilla@users.sourceforge.net>)
Re: Backend Stats Enhancement Request  (Thomas Lee <tom@vector-seven.com>)
List pgsql-hackers
Thomas Lee <tom@vector-seven.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Not valid dump [8.2.9, 8.3.1]
Next
From: "Joshua D. Drake"
Date:
Subject: Re: ...Roll Back issue in PGSQL..