Message-ID: <4E0B7F30.4090208@peak6.com>
Date: Wed, 29 Jun 2011 14:38:24 -0500
From: Shaun Thomas <sthomas@peak6.com>
Reply-To: <sthomas@peak6.com>
Organization: Peak6
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.13) Gecko/20101210 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: Greg Spiegelberg <gspiegelberg@gmail.com>
CC: Marinos Yannikos <mjy@geizhals.at>, <pgsql-performance@postgresql.org>,
	Svetlin Manavski <svetlin.manavski@gmail.com>
Subject: Re: is parallel union all possible over dblink?
References: <BANLkTimwCWg6LGavaNU3YMJNcBiWppX9UQ@mail.gmail.com>
	<op.vxuoogblkhmbxg@klump-pc.ghoffice>
	<BANLkTin_CFVj24_XX=+o_gZKtTCuqgENQg@mail.gmail.com>
In-Reply-To: <BANLkTin_CFVj24_XX=+o_gZKtTCuqgENQg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
content-transfer-encoding: 7bit

On 06/29/2011 02:14 PM, Greg Spiegelberg wrote:

> 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.

We actually demoed this as a proof of concept a while back. Even just 
having two instances on the same machine resulted in linear improvements 
in execution speed thanks to parallel query execution.

Setting it up is something of a PITA, though, and the metadata database 
is completely arbitrary. You basically must use the GridSQL intermediate 
layer if you ever want to see your data again. I wouldn't use it for 
anything but a reporting database that can be reconstructed if necessary.

-- 
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas@peak6.com

______________________________________________

See  http://www.peak6.com/email_disclaimer.php
for terms and conditions related to this email