public inbox for [email protected]
help / color / mirror / Atom feedFrom: David Rowley <[email protected]>
To: Jelte Fennema-Nio <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Melih Mutlu <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Thomas Munro <[email protected]>
Subject: Re: Flushing large data immediately in pqcomm
Date: Thu, 21 Mar 2024 10:54:22 +1300
Message-ID: <CAApHDvoHJYcv+RCeaXM3VL6_44CgfjLLzvBbVAPvVLEMDxUdDA@mail.gmail.com> (raw)
In-Reply-To: <CAGECzQT9gH6uUd9pnTC=NB7TSwiTsO3kxYH5BXraSy3549Oe_g@mail.gmail.com>
References: <CA+TgmoZDm5LHyLcRm2RTak_xbOcbiMyZvddZ7HSH+x-Lp9+BrQ@mail.gmail.com>
<CAGPVpCSPoks12A1Hv_XHKTozYbtRp7uAMOag64-v_wfRkWqNxw@mail.gmail.com>
<CA+TgmoZYS32e_t10Br3KD50vjUgr4i5yEtmcBKMeaX5AacYJDA@mail.gmail.com>
<CAGECzQTYUhnC1bO=zNiSpUgCs=hCYxVHvLD2doXNx3My6ZAC2w@mail.gmail.com>
<CA+TgmobpDvzyjQYX7_Y+gJFW=1_TLZt_EB71y30b0gtLBwfgAQ@mail.gmail.com>
<CAGPVpCTN-Z9F5Wsq+LEirAv5OYZWPj1j7mE_Yumqxebsdu8YKw@mail.gmail.com>
<CA+TgmoaMgFMkZZ7MJ=y=7rx195dZ1cViLGCVB8PP=oTGJ0eT=w@mail.gmail.com>
<[email protected]>
<CA+TgmoagV=W=fyY2Ln_8As+Z8QJSVvnoxbgE3u+ohggxo-cMZg@mail.gmail.com>
<CA+TgmoYs7QssFjJDUFtPkJk9U3Q_98NxWvq4sXeREZVdAyh2LQ@mail.gmail.com>
<[email protected]>
<CAGPVpCSX8bTF61ZL9jOgh1AaY3bgsWnQ6J7WmJK4TV0f2LPnJQ@mail.gmail.com>
<CA+TgmoYr+ThbKThynszV1UyosewyvUF8vqY-vKeSPGXCbgoniQ@mail.gmail.com>
<CAGECzQT9gH6uUd9pnTC=NB7TSwiTsO3kxYH5BXraSy3549Oe_g@mail.gmail.com>
On Fri, 15 Mar 2024 at 02:03, Jelte Fennema-Nio <[email protected]> wrote:
>
> On Thu, 14 Mar 2024 at 13:12, Robert Haas <[email protected]> wrote:
> >
> > On Thu, Mar 14, 2024 at 7:22 AM Melih Mutlu <[email protected]> wrote:
> > > 1- Even though I expect both the patch and HEAD behave similarly in case of small data (case 1: 100 bytes), the patch runs slightly slower than HEAD.
> >
> > I wonder why this happens. It seems like maybe something that could be fixed.
>
> some wild guesses:
> 1. maybe it's the extra call overhead of the new internal_flush
> implementation. What happens if you make that an inline function?
> 2. maybe swap these conditions around (the call seems heavier than a
> simple comparison): !pq_is_send_pending() && len >= PqSendBufferSize
I agree these are both worth trying. For #2, I wonder if the
pq_is_send_pending() call is even worth checking at all. It seems to
me that the internal_flush_buffer() code will just do nothing if
nothing is pending. Also, isn't there almost always going to be
something pending when the "len >= PqSendBufferSize" condition is met?
We've just added the msgtype and number of bytes to the buffer which
is 5 bytes. If the previous message was also more than
PqSendBufferSize, then the buffer is likely to have 5 bytes due to the
previous flush, otherwise isn't it a 1 in 8192 chance that the buffer
is empty?
If that fails to resolve the regression, maybe it's worth memcpy()ing
enough bytes out of the message to fill the buffer then flush it and
check if we still have > PqSendBufferSize remaining and skip the
memcpy() for the rest. That way there are no small flushes of just 5
bytes and only ever the possibility of reducing the flushes as no
pattern should cause the number of flushes to increase.
David
view thread (11+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Flushing large data immediately in pqcomm
In-Reply-To: <CAApHDvoHJYcv+RCeaXM3VL6_44CgfjLLzvBbVAPvVLEMDxUdDA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox