On Thu, Jun 30, 2011 at 3:02 AM, Svetlin Manavski
<svetlin.manavski@gmail.com> wrote:
I am now a bit puzzled after the initial satisfaction by Marinos' reply.
1. what do you mean exactly by "to ensure your UNION succeeds". The dblink docs do not mention anything about issues using directly the suggested dblink_send_query() + dblink_get_results(). What problems should I expect in using them as suggested by Marinos?
Admittedly, I hadn't used those specific dblink functions and imagined dblink_get_result() failing if the query on the connection wasn't finished. It appears now that after some experimentation that it's perfectly happy hanging until the query is finished executing.
2. If I understand correctly your method, it is not applicable from inside a stored procedure, is it? I need to keep all the business logic within PostgreSQL and provide just a clean interface to a simple GUI layer
Then dblink is your answer. My suggestion applies if you were implementing a solution in the application.
3. Unfortunately GridSQL and Pgpool-II do not seem mature and stable products to be used in commercial software. Neither one provides clear documentation. GridSQL has been discontinued and it is not clear what kind of future it will have. I have not tried GridSQL but I did try Pgpool-II. It is disappointing that it may stop working correctly even just because of the way you write the query (e.g. using uppercase in a field or using named field in group by, ecc.). Even worse, when it does not recognize something in the parallel query, it just provides incorrect result (from only the local DB) rather than raising an exception. So I guess Pgpool-II in its current state is good only for very simple applications, which are not supposed to be reliable at all.
Sorry for the confusion.
Greg