Re: Increasing the length of pg_stat_activity.current_query...
От | Greg Stark |
---|---|
Тема | Re: Increasing the length of pg_stat_activity.current_query... |
Дата | |
Msg-id | 87ekj4jd63.fsf@stark.xeocode.com обсуждение исходный текст |
Ответ на | 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...
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > Greg Stark <gsstark@mit.edu> writes: > >>> What do you think is broken about fragmented UDP packets? > > > Fragmentation happens at the IP protocol level, the kernel is responsible for > > reassembly. There's nothing for the application level to handle. > > And, by the same token, on platforms where it is broken there is nothing > we can do about it. Ok having read the source I think I see why we're talking past each other. The pgstat messages are indeed fixed size. So bumping the size up to 8k would mean *every* udp packet would be bumped up to 8k. However there's no good reason for that to be the case. recv(2) always returns exactly one packet and tells you how large it was. And in fact the PgStat_MsgHdr even has a redundant message size field that could serve the same purpose. So we actually have all the machinery needed twice over to avoid the fixed size messages. In fact looking over the code I think it would be simple to change this. I think it would be reasonable to make just the PgStat_MsgActivity variable sized. I'll look at it a bit more, I think it's well worth the slight code complexity, especially if it were only done for the one message type. This has potential to reduce the average size of these messages quite a lot. Potentially reducing the data being pumped through udp and the pipe buffer (?!) quite a lot. -- greg
В списке pgsql-hackers по дате отправления: