Re: Multiple queries in transit
От | Heikki Linnakangas |
---|---|
Тема | Re: Multiple queries in transit |
Дата | |
Msg-id | 4EAECCA8.9030902@enterprisedb.com обсуждение исходный текст |
Ответ на | Multiple queries in transit (Mark Hills <Mark.Hills@framestore.com>) |
Ответы |
Re: Multiple queries in transit
|
Список | 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
В списке pgsql-hackers по дате отправления: