Sean Chittenden <sean@chittenden.org> writes:
> 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.
Just as a point of reference, I've been processing my logs to see how large my
queries work out to. They seem to max out at just over 5k, (5330 bytes to be
exact).
This is excluding "CREATE FUNCTION" calls where the body of the function can
of course be much larger but isn't interesting for stats.
> 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
From my own experience I would suggest 8k. If it's good enough for NFS
defaults it ought to be good enough for Postgres.
Realistically, you shouldn't be expecting any real quantities of dropped
packets on a local area network, so fragmented UDP packets aren't really a
problem. Anyone running their stats collector over a long haul internet
connection with dropped packets is probably doing something pretty unusual.
I think historically implementations didn't handle fragmented UDP packets at
all, or perhaps not over 32k. But any platform today ought to be happy with
packets at least up to 32k and any modern platform quite a bit larger.
--
greg