Michael Clark <codingninja@xxxxxxxxx> 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 why this surprises you. The value of those functions is if your application can do something else useful while it's waiting. If the data comes back so fast that you can't afford any extra cycles expended on the client side, then you don't have any use for those functions. However, if you do have something useful to do, the problem with this example code is that it's not doing that, it's just spinning: > while ( ((consume_result = PQconsumeInput(self.db)) == 1) && > ((is_busy_result = PQisBusy(self.db)) == 1) ) > ; That's a busy-wait loop, so it's no wonder you're eating cycles there. You want to sleep, or more likely do something else productive, when there is no data available from the underlying socket. Usually the idea is to include libpq's socket in the set of files being watched by select() or poll(), and dispatch off to something that absorbs the data whenever you see some data is available to read. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
