On Tue, Jul 24, 2012 at 10:37 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> Either way, it looks like there's plausible paths to optimizing
>> repeated result fetch without having expose an alternate data-fetching
>> API and that the proposed implementation doesn't appear to be a wall
>> in terms of getting there. So I'm firmly in the non-exposed-rowbuf
>> camp, even if we can't expose an optimal implementation in time for
>> 9.2.
>
> Yeah, the schedule argument is a strong one. If we put in PQgetRowData
> now, we'll be stuck with it forevermore. It would be better to push
> that part of the patch to 9.3 so we can have more time to think it over
> and investigate alternatives. The single-row mode is already enough to
> solve the demonstrated client-side performance issues we know about.
> So IMO it would be a lot smarter to be spending our time right now on
> making sure we have *that* part of the patch right.
Just to show agreement: both PQgetRowData() and optimized PGresult
do not belong to 9.2.
Only open questions are:
* Is there better API than PQsetSingleRowMode()? New PQsend* functions is my alternative.
* Should we rollback rowBuf change? I think no, as per benchmark it performs better than old code.
> The thing I fundamentally don't like about PQsetSingleRowMode is that
> there's such a narrow window of time to use it correctly -- as soon as
> you've done even one PQconsumeInput, it's too late. (Or maybe not, if
> the server is slow, which makes it timing-dependent whether you'll
> observe a bug. Maybe we should add more internal state so that we can
> consistently throw error if you've done any PQconsumeInput?) The most
> obvious alternative is to invent new versions of the PQsendXXX functions
> with an additional flag parameter; but there are enough of them to make
> that not very attractive either.
It belongs logically together with PQsend, so if you don't like
current separation, then proper fix is to make them single
function call.
--
marko