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: 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:04:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Mar 30, 2012 at 11:59:12AM -0400, Tom Lane wrote:
> Marko Kreen <markokr(at)gmail(dot)com> writes:
> > On Thu, Mar 29, 2012 at 06:56:30PM -0400, Tom Lane wrote:
> >> Marko Kreen <markokr(at)gmail(dot)com> writes:
> >>> Second conclusion is that current dblink row-processor usage is broken
> >>> when user uses multiple SELECTs in SQL as dblink uses plain PQexec().
> >> Yeah.  Perhaps we should tweak the row-processor callback API so that
> >> it gets an explicit notification that "this is a new resultset".
> >> Duplicating PQexec's behavior would then involve having the dblink row
> >> processor throw away any existing tuplestore and start over when it
> >> gets such a call.
> >> 
> >> There's multiple ways to express that but the most convenient thing
> >> from libpq's viewpoint, I think, is to have a callback that occurs
> >> immediately after collecting a RowDescription message, before any
> >> rows have arrived.  So maybe we could express that as a callback
> >> with valid "res" but "columns" set to NULL?
> >> 
> >> A different approach would be to add a row counter to the arguments
> >> provided to the row processor; then you'd know a new resultset had
> >> started if you saw rowcounter == 0.  This might have another advantage
> >> of not requiring the row processor to count the rows for itself, which
> >> I think many row processors would otherwise have to do.
> > Try to imagine how final documentation will look like.
> > Then imagine documentation for PGrecvRow() / PQgetRow().
> What's your point, exactly?  PGrecvRow() / PQgetRow() aren't going to
> make that any better as currently defined, because there's noplace to
> indicate "this is a new resultset" in those APIs either.

Have you looked at the examples?  PQgetResult() is pretty good hint
that one resultset finished...


In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2012-03-30 16:11:09
Subject: Re: HTTP Frontend? (and a brief thought on materialized views)
Previous:From: Tom LaneDate: 2012-03-30 15:59:12
Subject: Re: Speed dblink using alternate libpq tuple storage

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