Обсуждение: Asynchronous Query processing
I have a need to do asynchronous query processing. I am a little confused by the order and frequency of calls. Can someone tell me if the below is correct? The code comments are littered with my questions.
PQsendQueryParams(pgconn, "SELECT ..", ....);
while(1)
{
epoll/poll/select PQsocket(pgconn) [read]
// call this each time poll indicates data is ready?
PQconsumeInput(pgconn);
// If isBusy returns 1, just poll again? Will this indicate 0 when I have a full PGResult set?
// Or, can it split the results of a single statement across multiple result sets.
if(PQisBusy())
conitnue;
// I know the docs say keep calling getResult until it returns NULL. In my
// case, I am wondering if that is needed. I only send one statement at a
// time to the server. The connection is not listening for notifies either. Do
// I still need to call getResult multiple times? I saw many examples online
// that DO NOT call it multiple times, all of them executed a single statement.
res = PQgetResult(pgconn);
process_results(res);
}
thanks, brendon
PQsendQueryParams(pgconn, "SELECT ..", ....);
while(1)
{
epoll/poll/select PQsocket(pgconn) [read]
// call this each time poll indicates data is ready?
PQconsumeInput(pgconn);
// If isBusy returns 1, just poll again? Will this indicate 0 when I have a full PGResult set?
// Or, can it split the results of a single statement across multiple result sets.
if(PQisBusy())
conitnue;
// I know the docs say keep calling getResult until it returns NULL. In my
// case, I am wondering if that is needed. I only send one statement at a
// time to the server. The connection is not listening for notifies either. Do
// I still need to call getResult multiple times? I saw many examples online
// that DO NOT call it multiple times, all of them executed a single statement.
res = PQgetResult(pgconn);
process_results(res);
}
thanks, brendon
In response to "Brendon Sablinski" <mapletide@gmail.com>:
> I have a need to do asynchronous query processing. I am a little confused
> by the order and frequency of calls. Can someone tell me if the below is
> correct? The code comments are littered with my questions.
>
> PQsendQueryParams(pgconn, "SELECT ..", ....);
>
> while(1)
> {
> epoll/poll/select PQsocket(pgconn) [read]
>
> // call this each time poll indicates data is ready?
> PQconsumeInput(pgconn);
What poll? PQconsumeInput()/PQisBusy() _is_ the poll.
Also, you should check the return code. If you get 0, something has gone wrong.
> // If isBusy returns 1, just poll again? Will this indicate 0 when I have
> a full PGResult set?
> // Or, can it split the results of a single statement across multiple
> result sets.
> if(PQisBusy())
> conitnue;
Is this just experimenting? Note that by simply staying within the loop,
you basically wrap asynchronous access with synchronous code. In your real
code, you should return to whatever else the program has to work on.
> // I know the docs say keep calling getResult until it returns NULL. In
> my
> // case, I am wondering if that is needed. I only send one statement at a
> // time to the server. The connection is not listening for notifies
> either. Do
> // I still need to call getResult multiple times? I saw many examples
> online
> // that DO NOT call it multiple times, all of them executed a single
> statement.
If you know for a fact that there are no more statements in processing, there's
no need to call PQgetResult() any more.
However, if you know for a fact that there could never be more than a single
query in the pipeline, it's unlikely that your code is written to handle
asynchronous processing.
> res = PQgetResult(pgconn);
>
> process_results(res);
> }
>
> thanks, brendon
>
--
Bill Moran
http://www.potentialtech.com
>>If you know for a fact that there are no more statements in processing, there's
>>no need to call PQgetResult() any more.
thanks, that is what I thought.
>>What poll? PQconsumeInput()/PQisBusy() _is_ the poll.
comsumeInput and isBusy is not a poll. A poll tells you if data is ready. When data is ready you can then call recv() w/o blocking your application. If you call consumeInput without verifying data is ready, recv() would block (unless you set the pgconn.sockfd to nonblocking mode).
>>Also, you should check the return code.
This is just an example of the flow and sequence of PQ calls.
>However, if you know for a fact that there could never be more than a single
>query in the pipeline, it's unlikely that your code is written to handle
>asynchronous processing.
Asynch doesn't mean you have to have multiple outstanding requests on a pgconn. All it means is that your application is not waiting for the PGResult, it gets it later when the server is done. It has nothing to do with how many results maybe pending. The application layer is queuing queries requests because they need to be exectued at different times from different clients. Batching doesn't work here.
thanks, brendon
>>no need to call PQgetResult() any more.
thanks, that is what I thought.
>>What poll? PQconsumeInput()/PQisBusy() _is_ the poll.
comsumeInput and isBusy is not a poll. A poll tells you if data is ready. When data is ready you can then call recv() w/o blocking your application. If you call consumeInput without verifying data is ready, recv() would block (unless you set the pgconn.sockfd to nonblocking mode).
>>Also, you should check the return code.
This is just an example of the flow and sequence of PQ calls.
>However, if you know for a fact that there could never be more than a single
>query in the pipeline, it's unlikely that your code is written to handle
>asynchronous processing.
Asynch doesn't mean you have to have multiple outstanding requests on a pgconn. All it means is that your application is not waiting for the PGResult, it gets it later when the server is done. It has nothing to do with how many results maybe pending. The application layer is queuing queries requests because they need to be exectued at different times from different clients. Batching doesn't work here.
thanks, brendon