Skip site navigation (1) Skip section navigation (2)

Re: Multiple queries in transit

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: (view raw, whole thread or download thread mbox)
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.

We do set TCP_NODELAY, see connectNoDelay() in fe-connect.c 

   Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Marti RaudseppDate: 2011-10-31 16:57:58
Subject: Re: Multiple queries in transit
Previous:From: Mark HillsDate: 2011-10-31 15:44:02
Subject: Multiple queries in transit

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group