Re: Speed dblink using alternate libpq tuple storage

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: Speed dblink using alternate libpq tuple storage
Дата
Msg-id CAM103DuBvgCta46RJgkwhMvTZd9VkPxYOhZ238Y+f8KmV18WXQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Speed dblink using alternate libpq tuple storage  (Marko Kreen <markokr@gmail.com>)
Ответы Re: Speed dblink using alternate libpq tuple storage  (Kyotaro HORIGUCHI <horiguchi.kyotaro@oss.ntt.co.jp>)
Список pgsql-hackers
<p>Thank you. Everything seems clear.<br /> Please wait for a while.<p>> PQskipResult:<br /> > - store old
callbackand param in local vars<br /> > - set do-nothing row callback<br /> > - call PQgetresu<blockquote
class="gmail_quote"style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Feb 21, 2012 at 12:13
PM,Kyotaro HORIGUCHI<br /> <<a href="mailto:horiguchi.kyotaro@oss.ntt.co.jp">horiguchi.kyotaro@oss.ntt.co.jp</a>>
wrote:<br/> >> > - PQskipResult(conn, true) makes all consequent PQgetResult()'s<br /> >> >  to skip
allthe rows.<br /> ><br /> > Well, Is this right?<br /><br /> Yes, call getResult() until it returns NULL.<br
/><br/> >> > If this is right, row processor should stay also in PGresult<br /> >> > context.
PQskipResult()replaces the row processor in PGconn when<br /> >> > the second parameter is true, and in
PGresultfor false.<br /> >><br /> >> No, let's keep row processor only under PGconn.<br /> ><br /> >
Then,Should I add the stash for the row processor (and needless<br /> > for param) to recall after in PGconn?<br
/><br/> PQskipResult:<br /> - store old callback and param in local vars<br /> - set do-nothing row callback<br /> -
callPQgetresult() once, or until it returns NULL<br /> - restore old callback<br /> - return 1 if last result was
non-NULL,0 otherwise<br /><br /> --<br /> marko<br /><br /></blockquote> 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: Access Error Details from PL/pgSQL
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Scaling XLog insertion (was Re: Moving more work outside WALInsertLock)