On Tue, Jul 24, 2012 at 10:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Merlin Moncure <mmonc...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
