Re: Speed dblink using alternate libpq tuple storage

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>, greg(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org, mmoncure(at)gmail(dot)com, shigeru(dot)hanada(at)gmail(dot)com
Subject: Re: Speed dblink using alternate libpq tuple storage
Date: 2012-03-30 16:30:24
Message-ID: CACMqXCKi1RjBgeY2mr=xns-WW-aGywXvMXO9Mk6Rb6XRdarrig@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 30, 2012 at 7:04 PM, Marko Kreen <markokr(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2012-03-30 16:31:56 checkpointer code behaving strangely on postmaster -T
Previous Message Robert Haas 2012-03-30 16:27:36 tracking context switches with perf record