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.
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 select()
On Thu, Oct 28, 2010 at 11:15 AM, A.M. age...@themactionfaction.com 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
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
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,
--
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.
To
Hello everyone.
I have been investigating the PG async calls and trying to determine whether
I should go down the road of using them.
In doing some experiments I found that using
PQsendQueryParams/PQconsumeInput/PQisBusy/PQgetResult produces slower
results than simply calling PQexecParams.
Upon
On Wed, Oct 27, 2010 at 15:02, Michael Clark codingni...@gmail.com 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
On Wed, Oct 27, 2010 at 5:02 PM, Michael Clark codingni...@gmail.comwrote:
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
Michael Clark codingni...@gmail.com 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
10 matches
Mail list logo
