Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 9E548B5DBDA for ; Thu, 30 Jun 2011 06:02:15 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 60435-01 for ; Thu, 30 Jun 2011 09:02:08 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-fx0-f47.google.com (mail-fx0-f47.google.com [209.85.161.47]) by mail.postgresql.org (Postfix) with ESMTP id 46C35B5DBDF for ; Thu, 30 Jun 2011 06:02:08 -0300 (ADT) Received: by fxg11 with SMTP id 11so2248545fxg.34 for ; Thu, 30 Jun 2011 02:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fgU+q2wZh7S1lw15MImwqE4ALhcUSJyV0eV4z5qT3qA=; b=kA2uUUD0BA+1dboEt3tWp8gAl4xmZKLJfC8Va3s/co8IFF/CHB3uoTmsga935x/ocr y8KHYGrzPE4XOHYQgISM2yQC5fD0Tgbpq5JFv5w2thcd+nZyCJN+Mtk7yxDkHWhqanB/ k0x7PO76xuQwl1MDe+TlLryUX7GlCKHdUvna0= MIME-Version: 1.0 Received: by 10.223.86.14 with SMTP id q14mr2631493fal.115.1309424527672; Thu, 30 Jun 2011 02:02:07 -0700 (PDT) Received: by 10.223.103.141 with HTTP; Thu, 30 Jun 2011 02:02:07 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Jun 2011 10:02:07 +0100 Message-ID: Subject: Re: is parallel union all possible over dblink? From: Svetlin Manavski To: Greg Spiegelberg Cc: Marinos Yannikos , pgsql-performance@postgresql.org Content-Type: multipart/alternative; boundary=20cf3054a70dd5073c04a6ea2706 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.898 tagged_above=-10 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 201107/1 X-Sequence-Number: 44213 --20cf3054a70dd5073c04a6ea2706 Content-Type: text/plain; charset=ISO-8859-1 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? 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 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. Thank you, Svetlin Manavski On Wed, Jun 29, 2011 at 8:14 PM, Greg Spiegelberg wrote: > > This does work however you'll need to add a little more to it to ensure > your UNION succeeds. In pseudo... > > connection #1: > CREATE TABLE target_1 ... > BEGIN; > LOCK TABLE target_1 IN ACCESS EXCLUSIVE MODE; > INSERT INTO target_1 SELECT ... > COMMIT; > > connection #2: > CREATE TABLE target_2 ... > BEGIN; > LOCK TABLE target_2 IN ACCESS EXCLUSIVE MODE; > INSERT INTO target_2 SELECT ... > COMMIT; > > connection #3: > SELECT * FROM target_1 UNION SELECT * FROM target_2; > > Connections 1 and 2 can be done in simultaneously and after both have > reached the LOCK statement then the SELECT on connection 3 can be executed. > Same fundamentals if all three connections are to different databases and > connection 3 uses dblink to pull the data. > > Another alternative is to use GridSQL. I haven't used it myself but seen > it in action on a large install with 4 backend databases. Pretty slick. > > Greg > > --20cf3054a70dd5073c04a6ea2706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am now a bit puzzled after the initial satisfaction by Marinos' reply= .

1. what do you mean exactly by "to ensure your UNION succeed= s". The dblink docs do not mention anything about issues using directl= y=A0 the suggested dblink_send_query() + dblink_get_results(). What problem= s should I expect in using them as suggested by Marinos?

2. If I understand correctly your method, it is not applicable from ins= ide 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

3. Unfortunately GridSQL and Pgpool-II do not seem mature and stable pr= oducts to be used in commercial software. Neither one provides clear docume= ntation. GridSQL has been discontinued and it is not clear what kind of fut= ure it will have. I have not tried GridSQL but I did try Pgpool-II. It is d= isappointing that it may stop working correctly even just because of the wa= y 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 th= e 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 sta= te is good only for very simple applications, which are not supposed to be = reliable at all.

Thank you,
Svetlin Manavski


On= Wed, Jun 29, 2011 at 8:14 PM, Greg Spiegelberg <gspiegelberg@gmail.com> = wrote:
=

This does work however you'll ne= ed to add a little more to it to ensure your UNION succeeds. =A0In pseudo..= .

connection #1:
CREATE TABLE target_1 ...
BEGIN;
LOCK TABLE target_1 IN ACCESS EXCLUSIVE MODE;
INSERT INTO target_1 SELECT ...
COMMIT;

connection #2:
CREATE TABLE target_2 ...
BEGIN;
LOCK TABLE target_2 IN ACCESS EXCLUSIVE MODE;
INSERT INTO targ= et_2 SELECT ...
COMMIT;

connection= #3:
SELECT * FROM target_1 UNION SELECT * FROM target_2;

Connections 1 and 2 can be done in simultaneously and after both ha= ve reached the LOCK statement then the SELECT on connection 3 can be execut= ed. =A0Same fundamentals if all three connections are to different database= s and connection 3 uses dblink to pull the data.

Another alternative is to use GridSQL. =A0I haven't= used it myself but seen it in action on a large install with 4 backend dat= abases. =A0Pretty slick.

Greg


--20cf3054a70dd5073c04a6ea2706--