Re: Increasing the length of pg_stat_activity.current_query... - Mailing list pgsql-hackers

From Sean Chittenden
Subject Re: Increasing the length of pg_stat_activity.current_query...
Date
Msg-id 78339866-3034-11D9-9442-000A95C705DC@chittenden.org
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...  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Increasing the length of pg_stat_activity.current_query...  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
>> I'm confused... UDP as in the UDP/IP?  RPC caps UDP messages at 8K and
>> NFS over UDP often runs at 32K...  where is UDP used in the backend?
>
> pgstat messages travel over UDP/IP.

Over the loopback interface, right?  Then why worry about 
fragmentation?  This seems like premature optimization/prevention.  A 
lost packet over lo0 is symptom of a bigger problem.  The contents of 
pgstat messages are probably the least of an admins concerns if that's 
happening.

Having a 1K query isn't uncommon on some of the stuff I work on, an 8K 
query... that's a tad different and would stick out like a sore thumb.  
Would you be open to increasing this further after the 8.0 release?  I 
haven't heard of anyone complaining about dropped/fragmented pgstat 
messages.  :)  -sc

-- 
Sean Chittenden



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