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

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: [HACKERS] libpq: why we need to fetch all rows?
Дата
Msg-id 990106ee975e2997c9bb1a4ceebdfa25
обсуждение исходный текст
Ответ на [HACKERS] libpq: why we need to fetch all rows?  (Alexander Demenshin <aldem@techie.com>)
Список pgsql-hackers
>
> On Sun, 29 Jun 1997, Bruce Momjian wrote:
>
> > > On Sun, 29 Jun 1997, Bruce Momjian wrote:
> > >
> > > 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.
>
> Well, you'd want to base this on the number of rows returned.  For small
> sets it would probably be best to just send it all to the client.
>
> Also, you could implament a low overhead table type to make this work
> better for large data sets.  Just do minimal indexing (Probably on
> an oid equiv.) and lay the data out in a way that is quick to write
> and retrieve.  For a lot of medium sized datasets you could just do
> this in memory.
>
> Of course I can see some security issues here.  You'd either want to
> make it hard for clients other than the one that created the table to
> get to the data, or at the very least make it difficult for the name of
> the temporary table to be guessed.

But then, what is the goal?  A temp table is going to be a performance
hit, and so is passing one row at a time from the backend.


- --
Bruce Momjian
maillist@candle.pha.pa.us

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

В списке pgsql-hackers по дате отправления: