Re: Flushing large data immediately in pqcomm

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: Flushing large data immediately in pqcomm
Date: 2024-03-14 12:30:19
Message-ID: CAGECzQQMktuTj8ijJgBRXCwLEqfJyAFxg1h7rCTej-6=cR0r=Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 14 Mar 2024 at 12:22, Melih Mutlu <m(dot)melihmutlu(at)gmail(dot)com> wrote:
> I did some experiments with this patch, after previous discussions

One thing I noticed is that the buffer sizes don't seem to matter much
in your experiments, even though Andres his expectation was that 1400
would be better. I think I know the reason for that:

afaict from your test.sh script you connect psql over localhost or
maybe even unix socket to postgres. Neither of those would not have an
MTU of 1500. You'd probably want to do those tests over an actual
network or at least change the MTU of the loopback interface. e.g. my
"lo" interface mtu is 65536 by default:

❯ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-03-14 12:34:37 Re: BitmapHeapScan streaming read user and prelim refactoring
Previous Message Daniel Gustafsson 2024-03-14 12:21:29 Re: small_cleanups around login event triggers