Re: Speed dblink using alternate libpq tuple storage - Mailing list pgsql-hackers

From Marko Kreen
Subject Re: Speed dblink using alternate libpq tuple storage
Date
Msg-id CACMqXCKi1RjBgeY2mr=xns-WW-aGywXvMXO9Mk6Rb6XRdarrig@mail.gmail.com
Whole thread Raw
In response to Re: Speed dblink using alternate libpq tuple storage  (Marko Kreen <markokr@gmail.com>)
List pgsql-hackers
On Fri, Mar 30, 2012 at 7:04 PM, Marko Kreen <markokr@gmail.com> wrote:
> Have you looked at the examples?  PQgetResult() is pretty good hint
> that one resultset finished...

Ok, the demos are around this long thread and hard to find,
so here is a summary of links:

Original design mail:
 http://archives.postgresql.org/message-id/20120224154616.GA16985@gmail.com

First patch with quick demos:
 http://archives.postgresql.org/message-id/20120226221922.GA6981@gmail.com

Demos as diff:
 http://archives.postgresql.org/message-id/20120324002224.GA19635@gmail.com

Demos/experiments/tests (bit messier than the demos-as-diffs):
 https://github.com/markokr/libpq-rowproc-demos

Note - the point is that user *must* call PQgetResult() when resultset ends.
Thus also the "PQgetRow() does not return errors" decision.

I'll put this mail into commitfest page too, seems I've forgotten to
put some mails there.

--
marko


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: tracking context switches with perf record
Next
From: Alvaro Herrera
Date:
Subject: checkpointer code behaving strangely on postmaster -T