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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
