Not necessarily. A join could produce some sort of temporary table (disk
based or in memory) and each row produced by the join assigned an Oid.
=+=------------------------/\---------------------------------=+=
Igor Natanzon |**| E-mail: igor@sba.miami.edu
=+=------------------------\/---------------------------------=+=
On Sun, 29 Jun 1997, Bruce Momjian wrote:
> >
> > 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.
>
> The problem is that most results are joins, and there are multiple oid's
> to deal with .
>
> --
> Bruce Momjian
> maillist@candle.pha.pa.us
>
------------------------------
