Re: [HACKERS] libpq: why we need to fetch all rows? - Mailing list pgsql-hackers

From Igor
Subject Re: [HACKERS] libpq: why we need to fetch all rows?
Date
Msg-id 770ad787eaaa92146d202702f25cde5e
Whole thread Raw
In response to [HACKERS] libpq: why we need to fetch all rows?  (Alexander Demenshin <aldem@techie.com>)
List pgsql-hackers
After the table is created it will be stored to disk (costly), but in
memory you would again keep only the Oid's so that malloc'ing every tuple
won't be necessary,  offsetting the cost of a temporary table.
Of course, we are talking about 10 - 100 thousand tuples where preloading
an entire table into memory wouldn't even be possible if machine doesn't
have enough ram..

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

On Sun, 29 Jun 1997, Bruce Momjian wrote:

> >
> > On Sun, 29 Jun 1997, Bruce Momjian wrote:
> >
> > > > 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 .
> >
> > In this case couldn't you create a temporary table and return the name
> > of the table to the client?  It could then "cursor" through the temporary
> > table.
>
> Yes, we could, but you would not want to do that all the time because of
> performance.  You would have to determine if that particulary select
> statement was going to need it.
>
> --
> Bruce Momjian
> maillist@candle.pha.pa.us
>

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

pgsql-hackers by date:

Previous
From: Igor
Date:
Subject: Re: [HACKERS] libpq: why we need to fetch all rows?
Next
From: Igor
Date:
Subject: Re: [HACKERS] libpq: why we need to fetch all rows?