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 по дате отправления:

Предыдущее
От: darrenk@insightdist.com (Darren King)
Дата:
Сообщение: Re: [HACKERS] database size
Следующее
От: darrenk@insightdist.com (Darren King)
Дата:
Сообщение: Linux/Alpha's s_lock.c and other ports...