Re: [HACKERS] I want to change libpq and libpgtcl for better handling of large query results
От | PostgreSQL |
---|---|
Тема | Re: [HACKERS] I want to change libpq and libpgtcl for better handling of large query results |
Дата | |
Msg-id | Pine.LNX.3.96.980106103350.1317F-100000@linux.tpd.deuroconsult.ro обсуждение исходный текст |
Ответ на | Re: [HACKERS] I want to change libpq and libpgtcl for better handling of large query results (The Hermit Hacker <scrappy@hub.org>) |
Список | 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@hub.org secondary: scrappy@{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
В списке pgsql-hackers по дате отправления: