Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67]) by hub.org (8.8.8/8.7.5) with ESMTP id MAA10183; Wed, 29 Apr 1998 12:05:32 -0400 (EDT) Received: (from maillist@localhost) by candle.pha.pa.us (8.8.5/8.8.5) id MAA18436; Wed, 29 Apr 1998 12:04:41 -0400 (EDT) From: Bruce Momjian Message-Id: <199804291604.MAA18436@candle.pha.pa.us> Subject: Re: [HACKERS] Revised proposal for libpq and FE/BE protocol changes To: tgl@sss.pgh.pa.us (Tom Lane) Date: Wed, 29 Apr 1998 12:04:41 -0400 (EDT) Cc: pgsql-hackers@postgreSQL.org, pgsql-interfaces@postgreSQL.org In-Reply-To: <8596.893860094@sss.pgh.pa.us> from "Tom Lane" at Apr 29, 98 10:28:14 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > That was something I asked about a few days ago, and didn't get any > responses suggesting that anyone thought it was likely to happen. > > We would need wholesale changes everywhere in the protocol to support > concurrent queries: answers and errors coming back would have to be > tagged to indicate which query they apply to. The lack of a tag in > the cancel message isn't the controlling factor. > > 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. If we can remove the exec() in 6.4, that will make backend startup even quicker. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)