Re: Protocol 3, Execute, maxrows to return, impact?
От | Stephen R. van den Berg |
---|---|
Тема | Re: Protocol 3, Execute, maxrows to return, impact? |
Дата | |
Msg-id | 20080713162218.GA2067@cuci.nl обсуждение исходный текст |
Ответ на | Re: Protocol 3, Execute, maxrows to return, impact? (Gregory Stark <stark@enterprisedb.com>) |
Ответы |
Re: Protocol 3, Execute, maxrows to return, impact?
Re: Protocol 3, Execute, maxrows to return, impact? |
Список | pgsql-hackers |
Gregory Stark wrote: >"Abhijit Menon-Sen" <ams@oryx.com> writes: >>> Interleaved retrieval using multiple portals is not what most >>> libraries support, I'd guess. >> My code did support that mode of operation in theory, but in practice >> in the few situations where I have needed to use something like it, I >> found it more convenient to open explicit cursors and FETCH from them >Note that using FETCH for each record means a round trip to the server for >each record. If you're dealing with a lot of records that could be a lot >slower than streaming them to the client as quickly as it can consume them. >Now I'm not sure anyone's actually done any experiments to optimize libpq or >other drivers to stream data efficiently, so I'm not sure how much you would >really lose in practice today. My Pike drivers now support multiple simultaneous portals and automatic streaming by presending overlapping Execute statements with a dynamically adapted fetchlimit calculated per select as the query progresses. The only support still lacking is COPY. -- Sincerely, Stephen R. van den Berg. In this signature, the concluding three words `were left out'.
В списке pgsql-hackers по дате отправления: