Re: Increasing the length of - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Increasing the length of
Date
Msg-id 1099776278.6942.370.camel@localhost.localdomain
Whole thread Raw
In response to Re: Increasing the length of pg_stat_activity.current_query...  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Increasing the length of pg_stat_activity.current_query...
List pgsql-hackers
On Sat, 2004-11-06 at 19:44, Tom Lane wrote:
> Sean Chittenden <sean@chittenden.org> writes:
> > Is there any reason the length of 
> > pg_catalog.pg_stat_activity.current_query is capped at 255 characters?  
> 
> The reason for a limit is to avoid fragmentation of UDP messages.
> I believe we've set it at 1K for 8.0, though, and if you are on
> a platform with a higher message size limit you could raise it more.
> 

Hopefully, that is an explanation and not a justification.

Assuming there is no actual barrier to change on that point...

Not having the whole query is painful. Raising it to 1K doesn't get
round the fact that it's the longer queries that tend to be the more
painful ones, and so they are the ones you want to trap in full and
EXPLAIN, so you can find out if they are *ever* coming back. 

The assumption that we are also logging queries is less likely to be
true. pg_stat_activity is a window into the dynamic activity of the
server and is used for to-the-minute administration. The query volume
may be too high to enable full query logging all of the time.

If somebody is bothered by UDP fragmentation, then they should ask for
only the first 255 chars, rather than doing a select * from
pg_stat_activity. If its a backward compatibility issue, perhaps we can
set up a view to fake it for those people.

I'd vote in favour of relaxing the limit entirely, as Sean suggests.

-- 
Best Regards, Simon Riggs



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Increasing the length of pg_stat_activity.current_query...
Next
From: Bruce Momjian
Date:
Subject: Re: relative_path() seems overly complicated and buggy