| From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp> |
|---|---|
| To: | markokr(at)gmail(dot)com |
| Cc: | greg(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org, mmoncure(at)gmail(dot)com, shigeru(dot)hanada(at)gmail(dot)com |
| Subject: | Re: Speed dblink using alternate libpq tuple storage |
| Date: | 2012-03-07 01:04:28 |
| Message-ID: | 20120307.100428.196909651.horiguchi.kyotaro@oss.ntt.co.jp |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dan Ports | 2012-03-07 02:05:01 | a slightly stale comment |
| Previous Message | Kyotaro HORIGUCHI | 2012-03-07 00:43:54 | Re: Speed dblink using alternate libpq tuple storage |