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 CAApHDvpqe93j8aETb384UpzXRw+axs=zB8_jHf51E+-FcBqcAw@mail.gmail.com
Whole thread Raw
In response to Re: Flushing large data immediately in pqcomm  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Sun, 7 Apr 2024 at 08:21, Andres Freund <andres@anarazel.de> wrote:
> I added WITH BINARY, SET STORAGE EXTERNAL and tested both unix socket and
> localhost. I also reduced row counts and iteration counts, because I am
> impatient, and I don't think it matters much here. Attached the modified
> version.

Thanks for the script.  I'm able to reproduce the speedup with your script.

I looked over the patch again and ended up making internal_flush an
inline function rather than a macro.  I compared the assembly produced
from each and it's the same with the exception of the label names
being different.

I've now pushed the patch.

One thing that does not seem ideal is having to cast away the
const-ness of the buffer in internal_flush_buffer().  Previously this
wasn't an issue as we always copied the buffer and passed that to
secure_write().  I wonder if it's worth seeing if we can keep this
buffer constant all the way to the socket write.

That seems to require modifying the following function signatures:
secure_write(), be_tls_write(), be_gssapi_write().  That's not an area
I'm familiar with, however.

David



pgsql-hackers by date:

Previous
From: Pavel Borisov
Date:
Subject: Re: Table AM Interface Enhancements
Next
From: Daniel Gustafsson
Date:
Subject: Re: Cluster::restart dumping logs when stop fails