On 31.10.2011 17:44, Mark Hills wrote:
> We have a user interface which fetches and displays many small pieces of
> distinct information from a PostgreSQL database.
>
> * fetches are simple lookups across a diverse set of tables,
> in response to events on another data source
>
> * uses PQsendQuery() on a non-blocking socket
>
> But data fetches visibly take some time -- libpq doesn't allow a second
> query to be sent until the first has been fully processed. The
> back-and-forth seems to give a bottleneck on the round-trip.
>
> Instead, it would be preferable to send multiple requests (down the TCP
> socket), and then receive multiple responses (in order).
>
> This would allow the sending, processing and receiving response to be
> interleaved much more reasonably, and reduce the delay.
>
> Could libpq be reasonably modified to allow this?
I believe it's doable in theory, no-one has just gotten around to it.
Patches are welcome.
> Also, whilst tracing code through to pqsecure_write(), I also wondered if
> some Nagle's algorithm on the socket is also introducing an additional
> delay? I can't see special consideration in the code for this (eg.
> TCP_NODELAY)
We do set TCP_NODELAY, see connectNoDelay() in fe-connect.c
(http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/interfaces/libpq/fe-connect.c;h=ed9dce941e1d57cce51f2c21bf29769dfe2ee542;hb=HEAD#l960)
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com