Skip site navigation (1) Skip section navigation (2)

Re: Backend Stats Enhancement Request

From: Thomas Lee <tom(at)vector-seven(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Miller <miller392(at)yahoo(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Backend Stats Enhancement Request
Date: 2008-06-22 17:55:13
Message-ID: 485E9201.1080308@vector-seven.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Thanks for the feedback Tom. An initial patch for this has been posted 
to pgsql-patches.

Cheers,
T

Tom Lane wrote:
> 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
>
>   


In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2008-06-22 18:34:23
Subject: Re: Backend Stats Enhancement Request
Previous:From: Bruce MomjianDate: 2008-06-22 03:10:55
Subject: PG Pool Party (formerly MomjiCon) date set

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group