From: | Marko Kreen <markokr(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Postgres Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [patch] libpq one-row-at-a-time API |
Date: | 2012-07-24 20:52:23 |
Message-ID: | CACMqXCLAZUSpXa0R6H-VuXbQVRao1=3_qX=vXoy1UQGjBzDMEQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 24, 2012 at 10: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.
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
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2012-07-24 21:35:57 | Re: [patch] libpq one-row-at-a-time API |
Previous Message | Marko Kreen | 2012-07-24 20:40:47 | Re: [patch] libpq one-row-at-a-time API |