Re: [patch] libpq one-row-at-a-time API - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [patch] libpq one-row-at-a-time API
Date
Msg-id 4741.1343834326@sss.pgh.pa.us
Whole thread Raw
In response to Re: [patch] libpq one-row-at-a-time API  (Marko Kreen <markokr@gmail.com>)
Responses Re: [patch] libpq one-row-at-a-time API
List pgsql-hackers
[ getting back to this now after assorted distractions ]

Marko Kreen <markokr@gmail.com> writes:
> Just to show agreement: both PQgetRowData() and optimized PGresult
> do not belong to 9.2.

OK, we're all on board with leaving those for later.

> Only open questions are:

> * 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.

> * 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.

So I'm working from the first set of patches in your message
<20120721194907.GA28021@gmail.com>.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: New statistics for WAL buffer dirty writes
Next
From: Peter Geoghegan
Date:
Subject: Re: Help me develop new commit_delay advice