Re: SELECT's take a long time compared to other DBMS
В списке pgsql-performance по дате отправления:
| От | Neil Conway |
|---|---|
| Тема | Re: SELECT's take a long time compared to other DBMS |
| Дата | |
| Msg-id | 1062729142.364.20.camel@tokyo обсуждение исходный текст |
| Ответ на | Re: SELECT's take a long time compared to other DBMS ("Relaxin" <noname@spam.com>) |
| Список | pgsql-performance |
On Thu, 2003-09-04 at 22:13, Relaxin wrote: > Finally, someone who will actually assume/admit that it is returning the > entire result set to the client. > Where as other DBMS manage the records at the server. Is there a reason you can't use cursors (explicitely, or via ODBC if it provides some glue on top of them) to keep the result set on the server? http://candle.pha.pa.us/main/writings/pgsql/sgml/sql-declare.html http://candle.pha.pa.us/main/writings/pgsql/sgml/sql-fetch.html > The next one is the handling of BLOBS. PG handles them like no other system > I have ever come across. Just FYI, you can use both the lo_*() functions, as well as simple bytea/text columns (which can be very large in PostgreSQL). -Neil
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера