#include <pipeline.hxx>
Inheritance diagram for pqxx::pipeline:
Public Types | |
typedef unsigned | query_id |
Public Member Functions | |
pipeline (transaction_base &t, const PGSTD::string &PName="") | |
~pipeline () throw () | |
query_id | insert (const PGSTD::string &) |
Add query to the pipeline. | |
void | complete () |
Wait for all ongoing or pending operations to complete. | |
void | flush () |
Forget all pending operations and retrieved results. | |
bool | is_running (query_id) const |
Has given query started yet? | |
bool | is_finished (query_id) const |
Is result for given query available? | |
result | retrieve (query_id) |
Retrieve result for given query. | |
PGSTD::pair< query_id, result > | retrieve () |
Retrieve oldest unretrieved result (possibly wait for one). | |
bool | empty () const throw () |
void | retain () |
Optimization control: don't start issuing yet, more queries are coming. | |
void | resume () |
Resume retained query emission (harmless when not needed). |
Feel free to pump as many queries into the pipeline as possible, even if they were generated after looking at a result from the same pipeline. To get the best possible throughput, try to make insertion of queries run as far ahead of results retrieval as possible; issue each query as early as possible and retrieve their results as late as possible, so the pipeline has as many ongoing queries as possible at any given time. In other words, keep it busy!
One warning: if any of the queries you insert leads to a syntactic error, the error may be returned as if it were generated by an older query. Future versions may try to work around this if working in a nontransaction.
|
|
|
|
|
|
|
Wait for all ongoing or pending operations to complete.
|
|
|
|
Forget all pending operations and retrieved results.
|
|
Add query to the pipeline. Queries are accumulated in the pipeline and sent to the backend in a concatenated format, separated by semicolons. The queries you insert must not use this construct themselves, or the pipeline will get hopelessly confused! |
|
Is result for given query available?
|
|
Has given query started yet?
|
|
Resume retained query emission (harmless when not needed).
|
|
Optimization control: don't start issuing yet, more queries are coming. The pipeline will normally issue the first query inserted into it to the backend, and accumulate any new queries inserted while it is executing; those will once again be issued at the earliest opportunity. This may not be optimal, since most of the pipeline's speed advantage comes from its ability to bundle queries together and issue them at once. The normal procedure will be too "eager" to provide the full benefit for that first query. Call retain() to tell the pipeline to hold off on issuing queries when you know that more queries are about to be inserted. Use resume() afterwards, or the queries may not be issued for some time. Query emission will be resumed implicitly, however, if results are requested for queries that have not yet been issued to the backend. For best performance, call retain() before inserting a batch of queries into a pipeline, and resume() directly afterwards to make sure the queries are sent to the backend. |
|
Retrieve oldest unretrieved result (possibly wait for one).
|
|
Retrieve result for given query. If the query failed for whatever reason, this will throw an exception. The function will block if the query has not finished yet. |