Re: Speed dblink using alternate libpq tuple storage
| От | Marko Kreen |
|---|---|
| Тема | Re: Speed dblink using alternate libpq tuple storage |
| Дата | |
| Msg-id | CACMqXCLJWhq=2DnTa8iahvdVTYyc_-uts_jPJRva-YOiXLyVRA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Speed dblink using alternate libpq tuple storage (Kyotaro HORIGUCHI <horiguchi.kyotaro@oss.ntt.co.jp>) |
| Ответы |
Re: Speed dblink using alternate libpq tuple storage
|
| Список | pgsql-hackers |
On Tue, Feb 21, 2012 at 12:13 PM, Kyotaro HORIGUCHI <horiguchi.kyotaro@oss.ntt.co.jp> wrote: >> > - PQskipResult(conn, true) makes all consequent PQgetResult()'s >> > to skip all the rows. > > Well, Is this right? Yes, call getResult() until it returns NULL. >> > If this is right, row processor should stay also in PGresult >> > context. PQskipResult() replaces the row processor in PGconn when >> > the second parameter is true, and in PGresult for false. >> >> No, let's keep row processor only under PGconn. > > Then, Should I add the stash for the row processor (and needless > for param) to recall after in PGconn? PQskipResult: - store old callback and param in local vars - set do-nothing row callback - call PQgetresult() once, or until it returns NULL - restore old callback - return 1 if last result was non-NULL, 0 otherwise -- marko
В списке pgsql-hackers по дате отправления: