Re: [HACKERS] Re: [INTERFACES] Revised proposal for libpq and FE/BE protocol changes
watts@humbug.antnet.com writes:
I suggest the application already has fork or fork/exec to
implement an asynchronous design.
True, if you don't mind assuming you have threads then you could
dedicate one thread to blocking in libpq while your other threads manage
your user interface and so forth. But most of these revisions would
still be useful in that situation. The current libpq does not cope well
with query strings containing multiple commands; it doesn't cope at all
with queries that return more than one type of tuple; it requires dummy
queries (wasting both processing time and network bandwidth) to check
for NOTIFY messages; and so forth. None of those problems can be solved
just by moving calls to libpq into a separate thread.
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofTue28Apr1998155324-0500199804282053.PAA21962@humbug.antnet.com
I have had a report from someone using Servlets, that they are opening
something like 5 to 10 connections from a single Java Servlet, which then
brokers them to clients.
-----Original Message-----
From: owner-pgsql-interfaces@hub.org
[mailto:owner-pgsql-interfaces@hub.org]On Behalf Of Tom Lane
Sent: Wednesday, April 29, 1998 3:28 PM
To: pgsql-hackers@postgreSQL.org; pgsql-interfaces@postgreSQL.org
Subject: [INTERFACES] Re: [HACKERS] Revised proposal for libpq and FE/BE
protocol changes
In the current system architecture, much the easiest way to execute
concurrent queries is to open up more than one connection. There's
nothing that says a frontend process can't fire up multiple backend
processes. I think this is probably sufficient, because I don't
foresee such a thing becoming really popular anyway.
Import Notes
Reply to msg id not found: 714F8949628ED1119E0F0060082C52F508445E@vesta.maidstone.gov.uk | Resolved by subject fallback