Re: Speed dblink using alternate libpq tuple storage

Поиск
Список
Период
Сортировка
От Kyotaro HORIGUCHI
Тема Re: Speed dblink using alternate libpq tuple storage
Дата
Msg-id 20120307.100428.196909651.horiguchi.kyotaro@oss.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Speed dblink using alternate libpq tuple storage  (Kyotaro HORIGUCHI <horiguchi.kyotaro@oss.ntt.co.jp>)
Список pgsql-hackers
Hello,

Nevertheless, the problem that exit from parseInput() caused by
non-zero return of getAnotherTuple() results in immediate
re-enter into getAnotherTuple() via parseInput() and no other
side effect is still there. But I will do that in the next patch,
though.

> So now I convinced that the whole row data is loaded at the point         ^am
> that getAnotherTuple is called. I agree that getAnotherTuple
> should not return EOF to request for unloaded part of the
> message.
> 
> Please wait for a while for the new patch.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center


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

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Speed dblink using alternate libpq tuple storage
Следующее
От: Dan Ports
Дата:
Сообщение: a slightly stale comment