Skip site navigation (1) Skip section navigation (2)

Re: Speed dblink using alternate libpq tuple storage

From: Marko Kreen <markokr(at)gmail(dot)com>
To: Shigeru Hanada <shigeru(dot)hanada(at)gmail(dot)com>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)oss(dot)ntt(dot)co(dot)jp>, mmoncure(at)gmail(dot)com,pgsql-hackers(at)postgresql(dot)org, greg(at)2ndquadrant(dot)com
Subject: Re: Speed dblink using alternate libpq tuple storage
Date: 2012-02-26 22:19:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Feb 24, 2012 at 05:46:16PM +0200, Marko Kreen wrote:
> - rename to PQrecvRow() and additionally provide PQgetRow()

I tried it and it seems to work as API - there is valid behaviour
for both sync and async connections.

Sync connection - PQgetRow() waits for data from network:

	if (!PQsendQuery(db, q))
		die(db, "PQsendQuery");
	while (1) {
		r = PQgetRow(db);
		if (!r)
	r = PQgetResult(db);

Async connection - PQgetRow() does PQisBusy() loop internally,
but does not read from network:

   on read event:
	while (1) {
		r = PQgetRow(db);
		if (!r)
	if (!PQisBusy(db))
		r = PQgetResult(db);

As it seems to simplify life for quite many potential users,
it seems worth including in libpq properly.

Attached patch is on top of v20120223 of row-processor
patch.  Only change in general code is allowing
early exit for syncronous connection, as we now have
valid use-case for it.


Attachment: pqgetrow.diff
Description: text/x-diff (8.9 KB)

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-02-26 22:53:53
Subject: Re: CLOG contention, part 2
Previous:From: Peter van HardenbergDate: 2012-02-26 20:22:31
Subject: Re: psql \i tab completion initialization problem on HEAD

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group