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

Поиск
Список
Период
Сортировка
От Marko Kreen
Тема Re: [patch] libpq one-row-at-a-time API
Дата
Msg-id CACMqXCKeK3eAa75Xq8OEOb-5SZfxbSqf7v6_ECVZnRffqFjY2w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [patch] libpq one-row-at-a-time API  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [patch] libpq one-row-at-a-time API
Список pgsql-hackers
On Wed, Aug 1, 2012 at 6:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Marko Kreen <markokr@gmail.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.GA28021@gmail.com>.

Great!

-- 
marko


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Gabriele Bartolini
Дата:
Сообщение: Re: [PATCH] Support for foreign keys with arrays
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [patch] libpq one-row-at-a-time API