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

From David Rowley
Subject Re: Flushing large data immediately in pqcomm
Date
Msg-id CAApHDvoxAnbaxRnn=uEZow_xMK=dEqHHKksTHVRMtK4sNRt2_Q@mail.gmail.com
Whole thread Raw
In response to Re: Flushing large data immediately in pqcomm  (Melih Mutlu <m.melihmutlu@gmail.com>)
Responses Re: Flushing large data immediately in pqcomm
Re: Flushing large data immediately in pqcomm
List pgsql-hackers
On Fri, 22 Mar 2024 at 12:46, Melih Mutlu <m.melihmutlu@gmail.com> wrote:
> I did all of the above changes and it seems like those resolved the regression issue.

Thanks for adjusting the patch.   The numbers do look better, but on
looking at your test.sh script from [1], I see:

meson setup --buildtype debug -Dcassert=true
--prefix="$DESTDIR/usr/local/pgsql" $DESTDIR && \

can you confirm if the test was done in debug with casserts on?   If
so, it would be much better to have asserts off and have
-Dbuildtype=release.

I'm planning to run some benchmarks tomorrow.   My thoughts are that
the patch allows the memcpy() to be skipped without adding any
additional buffer flushes and demonstrates a good performance increase
in various scenarios from doing so.  I think that is a satisfactory
goal. If I don't see any issues from reviewing and benchmarking
tomorrow, I'd like to commit this.

Robert, I understand you'd like a bit more from this patch. I'm
wondering if you planning on blocking another committer from going
ahead with this? Or if you have a reason why the current state of the
patch is not a meaningful enough improvement that would justify
possibly not getting any improvements in this area for PG17?

David

[1] https://www.postgresql.org/message-id/CAGPVpCSX8bTF61ZL9jOgh1AaY3bgsWnQ6J7WmJK4TV0f2LPnJQ%40mail.gmail.com



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Parallel Aggregates for string_agg and array_agg
Next
From: Ajin Cherian
Date:
Subject: Re: Skip collecting decoded changes of already-aborted transactions