Re: Flushing large data immediately in pqcomm
От | Robert Haas |
---|---|
Тема | Re: Flushing large data immediately in pqcomm |
Дата | |
Msg-id | CA+TgmoYs7QssFjJDUFtPkJk9U3Q_98NxWvq4sXeREZVdAyh2LQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Flushing large data immediately in pqcomm (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Flushing large data immediately in pqcomm
|
Список | pgsql-hackers |
On Thu, Feb 1, 2024 at 10:52 AM Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Jan 31, 2024 at 10:24 PM Andres Freund <andres@anarazel.de> wrote: > > While not perfect - e.g. because networks might use jumbo packets / large MTUs > > and we don't know how many outstanding bytes there are locally, I think a > > decent heuristic could be to always try to send at least one packet worth of > > data at once (something like ~1400 bytes), even if that requires copying some > > of the input data. It might not be sent on its own, but it should make it > > reasonably unlikely to end up with tiny tiny packets. > > I think that COULD be a decent heuristic but I think it should be > TESTED, including against the ~3 or so other heuristics proposed on > this thread, before we make a decision. > > I literally mentioned the Ethernet frame size as one of the things > that we should test whether it's relevant in the exact email to which > you're replying, and you replied by proposing that as a heuristic, but > also criticizing me for wanting more research before we settle on > something. Are we just supposed to assume that your heuristic is > better than the others proposed here without testing anything, or, > like, what? I don't think this needs to be a completely exhaustive or > exhausting process, but I think trying a few different things out and > seeing what happens is smart. There was probably a better way to phrase this email ... the sentiment is sincere, but there was almost certainly a way of writing it that didn't sound like I'm super-annoyed. Apologies for that. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: