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

Поиск
Список
Период
Сортировка
От Igor
Тема Re: [HACKERS] libpq: why we need to fetch all rows?
Дата
Msg-id 770ad787eaaa92146d202702f25cde5e
обсуждение исходный текст
Ответ на [HACKERS] libpq: why we need to fetch all rows?  (Alexander Demenshin <aldem@techie.com>)
Список 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 по дате отправления: