Re: Flushing large data immediately in pqcomm - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Flushing large data immediately in pqcomm
Date
Msg-id CA+TgmoagV=W=fyY2Ln_8As+Z8QJSVvnoxbgE3u+ohggxo-cMZg@mail.gmail.com
Whole thread Raw
In response to Re: Flushing large data immediately in pqcomm  (Andres Freund <andres@anarazel.de>)
Responses Re: Flushing large data immediately in pqcomm
List 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 by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
Next
From: Michail Nikolaev
Date:
Subject: Re: Revisiting {CREATE INDEX, REINDEX} CONCURRENTLY improvements