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-08-01 19:44:57
Message-ID: CACMqXCKeK3eAa75Xq8OEOb-5SZfxbSqf7v6_ECVZnRffqFjY2w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 1, 2012 at 6:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Marko Kreen <markokr(at)gmail(dot)com> writes:
>> * Is there better API than PQsetSingleRowMode()? New PQsend*
>> functions is my alternative.
>
> After thinking it over, I'm really unexcited about adding new versions
> of all the PQsend functions. If we had the prospect of more flags in
> future that could be added to a bitmask flags argument, it would be
> more palatable, but it's far from clear what those might be. So I'm
> now leaning towards using PQsetSingleRowMode as-is.

I can imagine such flag - I'd like to have a flag to allow send more
queries to server without waiting the finish of old ones.

Currently, when a batch-processing app wants to keep
backend busy, they need to stuff many statements into
single query. Which is ugly. Among other things it
loses the possibility to separate arguments from query,
and it breaks error reporting. The flag would fix this,
and it would be useful also in other scenarios.

Interestingly, although it affects different area, it would be also
be flag for PQsend* and not for PQexec*. So maybe
the direction is not completely wrong.

But I cannot imagine why the PQsetSingleRowMode would be
hard to keep working even if we have PQsend functions with flags,
so I'm not worried about getting it exactly right from the start.

>> * Should we rollback rowBuf change? I think no, as per benchmark
>> it performs better than old code.
>
> I had already pretty much come to that conclusion just based on code
> review, without thinking about performance. In particular, we had done
> some nontrivial work towards improving error-case handling in the data
> message parsing code, and I don't really want to give that up, nor
> rewrite it on the fly now. About the only reason I could see for
> reverting rowBuf was that I thought it might hurt performance; so now
> that you've proven the opposite, we should leave it alone.

Additional argument for rowBuf is Merlin's wish for weirdly optimized
PGresults. Basically, with rowBuf anybody who wants to experiment
with different ways to process row data just needs to implement
single function which processes data then advances the state
machine. Like I did with PQgetRowData().

Without it, quite lot of code needs to be patched.

> So I'm working from the first set of patches in your message
> <20120721194907(dot)GA28021(at)gmail(dot)com>.

Great!

--
marko

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-08-02 05:19:46 Re: [patch] libpq one-row-at-a-time API
Previous Message Gabriele Bartolini 2012-08-01 17:53:26 Re: [PATCH] Support for foreign keys with arrays