Re: Increasing the length of pg_stat_activity.current_query...
| От | Sean Chittenden |
|---|---|
| Тема | Re: Increasing the length of pg_stat_activity.current_query... |
| Дата | |
| Msg-id | 78339866-3034-11D9-9442-000A95C705DC@chittenden.org обсуждение исходный текст |
| Ответ на | 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...
Re: Increasing the length of pg_stat_activity.current_query... |
| Список | 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 по дате отправления: