From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Mark Hills <Mark(dot)Hills(at)framestore(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Multiple queries in transit |
Date: | 2011-10-31 16:28:24 |
Message-ID: | 4EAECCA8.9030902@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Marti Raudsepp | 2011-10-31 16:57:58 | Re: Multiple queries in transit |
Previous Message | Mark Hills | 2011-10-31 15:44:02 | Multiple queries in transit |