Re: Flushing large data immediately in pqcomm

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Flushing large data immediately in pqcomm
Дата
Msg-id CA+TgmoagV=W=fyY2Ln_8As+Z8QJSVvnoxbgE3u+ohggxo-cMZg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Flushing large data immediately in pqcomm  (Andres Freund <andres@anarazel.de>)
Ответы Re: Flushing large data immediately in pqcomm  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
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.

--
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
Следующее
От: Michail Nikolaev
Дата:
Сообщение: Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements