Re: [HACKERS] libpq: why we need to fetch all rows?
| От | Michael J. Miller Jr. |
|---|---|
| Тема | Re: [HACKERS] libpq: why we need to fetch all rows? |
| Дата | |
| Msg-id | e7933222c4b809e8728a14f61df5bc2e обсуждение исходный текст |
| Ответ на | [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. Mike Miller mke@netcom.com ------------------------------
В списке pgsql-hackers по дате отправления: