Обсуждение: Wishes for PostgreSQL 6.4

Tom Lane wrote:
>
> 6.4-BETA1 doesn't work with Tcl 8.*.  The current snapshot does though.
> Also I think a BETA2 tarball should be out today or tomorrow.

It's just fine. I'll wait for it.
I just wanted to test 6.4 BETA against PgAccess and maybe make some
improvements to PgAccess in order to release a new version of PgAccess
with 6.4

It's there something "Libpgtcl now gets async notifies from libpq(Tom)".

What means that ? Is there something that could improve PgAccess ?
The most important thing that could improve PgAccess would be another
implementation of pg_select.

For the moment, pg_select is issuing a "select" statement to backend IS
WAITING FOR ALL DATA TO COME, and then process the tcl loop.
It would be smarter to do something like that :

pg_select : "command sent to backend"
loop
    wait for another tuple to come
    if (end_of_records) break
    process tcl loop script
endofloop

any chance to implement such a behavior in the future ?

Under a real multitasking environment and working with a server across a
network, this would reduce the time of processing selects that could be
executed in the same time that data is coming through the wire. Also,
will be memory consumption reduction, because every tuple can be
released after tcl loop processing, instead of buffering the WHOLE query
result in the local memory.
--
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA

Constantin Teodorescu <teo@flex.ro> writes:
> It's there something "Libpgtcl now gets async notifies from libpq(Tom)".
> What means that ? Is there something that could improve PgAccess ?

If you want to listen for notifies, you just have to do "pg_listen".
The bit of code you specify is automatically executed from the Tcl idle
loop whenever a matching notify message arrives, just like button
callbacks and such.  The old "pg_notifies" (sp?) command is not needed
anymore.

> For the moment, pg_select is issuing a "select" statement to backend IS
> WAITING FOR ALL DATA TO COME, and then process the tcl loop.

We speculated a while back about extending PQgetResult to be able to
return partial result sets, say by specifying an upper limit on the
number of tuples per result set.  (Setting the upper limit to be one,
as you imply, is probably not very efficient ... I'd guess a few dozen
tuples per cycle might be reasonable.)  Once that was done pg_select
could be rewritten to make use of it.  It's not going to happen for
6.4, obviously.  Maybe for 6.5.

            regards, tom lane