Skip site navigation (1) Skip section navigation (2)

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

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Merlin MoncureDate: 2012-07-24 21:35:57
Subject: Re: [patch] libpq one-row-at-a-time API
Previous:From: Marko KreenDate: 2012-07-24 20:40:47
Subject: Re: [patch] libpq one-row-at-a-time API

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group