Re: ResultSet storing all rows with defaulftFetchSize to 5000

Поиск
Список
Период
Сортировка
Искать
От
Vladimir Sitnikov
Тема
Re: ResultSet storing all rows with defaulftFetchSize to 5000
Дата
Msg-id
CAB=Je-G-_m46JH85Sg=PAg3BqExF-oELutUxNipaJMW-v_CemA@mail.gmail.com
Ответ на
Список
Дерево обсуждения
ResultSet storing all rows with defaulftFetchSize to 5000 Jaime Soler <jaime.soler@gmail.com>
Re: ResultSet storing all rows with defaulftFetchSize to 5000 Brad DeJong <bpd0018@gmail.com>
Re: ResultSet storing all rows with defaulftFetchSize to 5000 Dave Cramer <pg@fastcrypt.com>
Re: ResultSet storing all rows with defaulftFetchSize to 5000 Mark Rotteveel <mark@lawinegevaar.nl>
Re: ResultSet storing all rows with defaulftFetchSize to 5000 Dave Cramer <pg@fastcrypt.com>
Re: ResultSet storing all rows with defaulftFetchSize to 5000 Jaime Soler <jaime.soler@gmail.com>
Re: ResultSet storing all rows with defaulftFetchSize to 5000 Vladimir Sitnikov <sitnikov.vladimir@gmail.com>
Re: ResultSet storing all rows with defaulftFetchSize to 5000 Tom Lane <tgl@sss.pgh.pa.us>
Re: ResultSet storing all rows with defaulftFetchSize to 5000 Vladimir Sitnikov <sitnikov.vladimir@gmail.com>
Re: ResultSet storing all rows with defaulftFetchSize to 5000 Tom Lane <tgl@sss.pgh.pa.us>
Re: ResultSet storing all rows with defaulftFetchSize to 5000 Vladimir Sitnikov <sitnikov.vladimir@gmail.com>
Re: ResultSet storing all rows with defaulftFetchSize to 5000 Tom Lane <tgl@sss.pgh.pa.us>
Re: ResultSet storing all rows with defaulftFetchSize to 5000 Vladimir Sitnikov <sitnikov.vladimir@gmail.com>
Re: ResultSet storing all rows with defaulftFetchSize to 5000 Jaime Soler <jaime.soler@gmail.com>
Re: ResultSet storing all rows with defaulftFetchSize to 5000 Dave Cramer <pg@fastcrypt.com>
Re: ResultSet storing all rows with defaulftFetchSize to 5000 Dave Cramer <pg@fastcrypt.com>
>(Yes, we do support WITH HOLD.)

Oh, is it something available through extended query protocol?

The documentation says "If successfully created, a named portal object lasts till the end of the current transaction, unless explicitly destroyed", however I just hope it is a documentation bug and one can create a named portal that can survive transaction end.

I don't think explicit "fetch ... from ..." is a workable solution for pgjdbc as it would incur high overhead (both maintenance, and performance):
1) declare ... binary is either full-binary or full text. pgjdbc implements just a subset of binary formats
2) `fetch ...` cannot be prepared, so I expect more network traffic and parse/execute overhead
3) Reimplementing "frontend" from "ExtendedQuery" to "Declare/fetch" is a great amount of work

Vladimir
В списке pgsql-jdbc по дате отправления
От: Dave Cramer
Дата:
От: Tom Lane
Дата:
FAQ