Re: [HACKERS] libpq: why we need to fetch all rows?

What could be done (and this is similar to what PROGRESS database does..I
think)...
You could request a select on a very large table. The server will NOT
load all tuples that match the select, but only the Oid's of these tuples.
When you are ready to read data, you do fetch, at which time the oid is
used to get an entire tuple. So neither the server nor the client ever
keep in memory more than one tuple at a time. This might not even be too
hard to implement..A list of Oid could be a double-linked list withch
would make it easy to traverse it back and forth with NEXT/ PREV and other
statements. A lookup table of portals/cursors and their corresponding Oid
tables could be maintained by the server.

=+=------------------------/\---------------------------------=+=
       Igor Natanzon      |**|   E-mail: igor@sba.miami.edu
=+=------------------------\/---------------------------------=+=

On Sun, 29 Jun 1997, Bruce Momjian wrote:

> > Please give examples of true RDBMS SQL servers which return rows before
> > completing the database scan.
>
> My comments exactly.  I know of no such SQL engine.  Now, there are some
> which will keep the RESULTS on the server, and only return them
> one-by-one.  That may be a speed savings.  Also, if your query uses
> ORDER BY, I am in the process of improving the performance of that code.
>
> --
> Bruce Momjian
> maillist@candle.pha.pa.us
>

------------------------------