Re: [patch] libpq one-row-at-a-time API

On Tue, Jul 24, 2012 at 2:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)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.
>
> In particular I agree that PQsetSingleRowMode is a bit ugly, so I'm
> wondering about your thoughts on providing PQgetSingleRowResult instead.
> I don't see how to make that work in async mode. I think the library
> needs to be aware of whether it's supposed to return a single-row result
> in advance of actually doing so --- for instance, how can PQisBusy
> possibly give the correct answer if it doesn't know whether having
> received the first row is sufficient?

Well (Marko probably wants to slap me with a halibut by now), the
original intent was for it not to have to: PQgetSingleRowResult is
more 'construct result for single row iteration', so it would never
block -- it only sets the internal single row mode and instantiates
the result object. After that, you can do do standard
consumeinput/isbusy processing on the conn. The actual iteration
routine would be like PQiterateResult which you could guard with
PQisBusy. Like I said: it's the same general structure but the result
construction is moved out of the loop.

I don't think this breaks result scoping rules...the conn keeps a copy
of the result during 'result construction' which we are going to
define as ending when the query terminates. Until the query resolves,
the result remains 'under construction' and avoids the expectation of
const-ness that you normally get so you don't get to interleave
threads reading the result with threads iterating from the connection
(which is fine) and you have to avoid doing stupid things like closing
the connection before all the data has been read through.

(but maybe all this is moot per Marko's latest benchmarks)

merlin