| From: | PostgreSQL <postgres(at)deuroconsult(dot)ro> |
|---|---|
| To: | The Hermit Hacker <scrappy(at)hub(dot)org> |
| Cc: | Constantin Teodorescu <teo(at)flex(dot)ro>, pgsql-hackers(at)postgreSQL(dot)org, mviorel(at)flex(dot)ro |
| Subject: | Re: [HACKERS] I want to change libpq and libpgtcl for better handling of large query results |
| Date: | 1998-01-06 08:39:21 |
| Message-ID: | Pine.LNX.3.96.980106103350.1317F-100000@linux.tpd.deuroconsult.ro |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
As far as I understood, this seems to be another solution to the older
problem of speeding up the browser display of large results. The first one
consisted on nonblocking exec/blocking fetchtuple in libpq (the patch is
very simple). But the main point is that I learned at that time that
backend send tuples as soon as it computes them.
Can someone give an authorized answer?
On Tue, 6 Jan 1998, The Hermit Hacker wrote:
> On Mon, 5 Jan 1998, Constantin Teodorescu wrote:
...
>
> Now, from reading Bruce's email before reading this, this doesn't get
> around the fact that the backend is still going to have to finish generating
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> a response to the query before it can send *any* data back, so, as Bruce has
...
>
> Marc G. Fournier
> Systems Administrator @ hub.org
> primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org
>
PS. On the other hand, if someone is working on back/front protocol, could
he think about how difficult would be to have a async full duplex
connection?
Costin Oproiu
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter T Mount | 1998-01-06 12:07:07 | Re: [HACKERS] I want to change libpq and libpgtcl for better handling of large query results |
| Previous Message | Constantin Teodorescu | 1998-01-06 07:32:26 | Re: [HACKERS] I want to change libpq and libpgtcl for better handling of large query results |