[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-bugs
Subject:    Re: BUG #17005: Enhancement request: Improve walsender throughput by aggregating multiple messages i
From:       Amit Kapila <amit.kapila16 () gmail ! com>
Date:       2021-05-22 5:51:46
Message-ID: CAA4eK1+rDAVZRzbendZPdFCAWfy9qvVousyyvyujTg9KeCyiog () mail ! gmail ! com
[Download RAW message or body]

On Mon, May 17, 2021 at 4:14 AM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2021-05-13 00:31:53 +0000, PG Bug reporting form wrote:
> > I measured the throughput of reading the logical replication slot and found
> > that in smaller row size (512 bytes) the throughput is 50% lower compared to
> > 1024 bytes.
>
> Huh, that is interesting.
>
>
> > tcpdump shows that ethernet packets sent by the replication server contain
> > only one message per packet (see tcpdump output below).
> > May be this is the intended design to achieve low latency but this is not
> > favorable in application that requires high throughput.
>
> What kind of network is this? I would have expected that if the network
> can't keep up the small sends would end up getting aggregated into
> larger packets anyway? Are you hitting a PPS limit due to the small
> packages, but not yet the throughput limit?
>
>
> > Is it possible for PostgreSQL to enable Nagle's algorithm on the streaming
> > socket for replication?
> > Or aggegate the messages manually before sending them in one send()?
>
> I think we can probably do better in cases a transaction is more than a
> single change - but I don't think either enabling nagle's or aggregation
> are really an option in case of single row transactions. The latency
> impact for some scenarios seems too high.
>

Can we think of combining Begin single_change Commit and send them as
one message for a single-row change xacts?

-- 
With Regards,
Amit Kapila.


[prev in list] [next in list] [prev in thread] [next in thread]