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 по дате отправления: