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 some investigation I found that not calling PQconsumeInput/PQisBusy produces results in line with PQexecParams (which PQexecParams seems to be doing under the hood). I profiled my test and found this calling stack: (This is OS X 10.6) lo_unix_scall recvfrom$UNIX2003 recv$UNIX2003 pqsecure_read pqReadData PQconsumeInput ..... This showed up as the hottest part of the execution by far. This was a pretty simple test of fetching 6000+ rows. If I remove the PQconsumeInput/PQisBusy calls, which essentially makes the code blocking this hot spot goes away. Fetching 1000 rows goes from <.5 seconds to >3 seconds when I have the PQconsumeInput/PQisBusy calls in. I was wondering if maybe I am doing something wrong, or if there is a technique that might help reduce this penalty? Thanks in advance for any suggestions, Michael. P.S. here is a code snippet of what I am doing basically: (please keep in mind this is just test code and rather simplistic...) int send_result = PQsendQueryParams(self.db, [sql UTF8String], i, NULL, (const char *const *)vals, (const int *)lens, (const int *)formats, kTextResultFormat); int consume_result = 0; int is_busy_result = 0; while ( ((consume_result = PQconsumeInput(self.db)) == 1) && ((is_busy_result = PQisBusy(self.db)) == 1) ) ; if (consume_result != 1) NSLog(@"Got an error in PQconsumeInput"); PGresult* res = PQgetResult(self.db); while (PQgetResult(self.db) != NULL) NSLog(@"Oops, seems we got an extra response?");