On Oct 28, 2010, at 12:04 PM, Daniel Verite wrote:
> A.M. wrote:
>
>> In PostgreSQL, query canceling is implemented by opening a
>> second connection and passing specific data which is received
>> from the first connection
>
> With libpq's PQCancel(), a second connection is not necessary.
Michael Clark wrote:
> I guess I can have one thread performing the query using the non async PG
> calls, then from another thread issue the cancellation. Both threads
> accessing the same PGconn ?
Yes. See http://www.postgresql.org/docs/9.0/static/libpq-cancel.html
Best regards,
--
Da
A.M. wrote:
> In PostgreSQL, query canceling is implemented by opening a
> second connection and passing specific data which is received
> from the first connection
With libpq's PQCancel(), a second connection is not necessary.
Best regards,
--
Daniel
PostgreSQL-powered mail user agent
On Thu, Oct 28, 2010 at 11:15 AM, A.M. wrote:
>
> On Oct 28, 2010, at 11:08 AM, Michael Clark wrote:
>
> > Hello all.
> >
> > Thanks a lot for the responses, they are appreciated.
> >
> > I think I now understand the folly of my loop, and how that was
> negatively
> > impacting my "test".
> >
> >
On Oct 28, 2010, at 11:08 AM, Michael Clark wrote:
> Hello all.
>
> Thanks a lot for the responses, they are appreciated.
>
> I think I now understand the folly of my loop, and how that was negatively
> impacting my "test".
>
> I tried the suggestion Alex and Tom made to change my loop with a
Hello all.
Thanks a lot for the responses, they are appreciated.
I think I now understand the folly of my loop, and how that was negatively
impacting my "test".
I tried the suggestion Alex and Tom made to change my loop with a select()
and my results are now very close to the non-async version.
Michael Clark writes:
> In doing some experiments I found that using
> PQsendQueryParams/PQconsumeInput/PQisBusy/PQgetResult produces slower
> results than simply calling PQexecParams.
Well, PQconsumeInput involves at least one extra kernel call (to see
whether data is available) so I don't know
On Wed, Oct 27, 2010 at 5:02 PM, Michael Clark wrote:
>
> while ( ((consume_result = PQconsumeInput(self.db)) == 1) &&
> ((is_busy_result = PQisBusy(self.db)) == 1) )
> ;
>
>
> The problem with this code is that it's effectively useless as a test.
You're just spinning in a loop; if you
On Wed, Oct 27, 2010 at 15:02, Michael Clark wrote:
> Hello everyone.
> Upon some investigation I found that not calling PQconsumeInput/PQisBusy
> produces results in line with PQexecParams (which PQexecParams seems to be
> doing under the hood).
> (please keep in mind this is just test code and
