Received: from malur.postgresql.org ([217.196.149.56])
 by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from
 <pgsql-performance-owner+M51688=pgsql-performance-ar@postgresql.org>)
 id 1WkJOx-0006vB-E5
 for pgsql-performance@arkaria.postgresql.org; Tue, 13 May 2014 20:34:15 +0000
Received: from localhost ([127.0.0.1] helo=postgresql.org)
 by malur.postgresql.org with smtp (Exim 4.80) (envelope-from
 <pgsql-performance-owner+M51688=pgsql-performance-ar@postgresql.org>)
 id 1WkJOw-00079s-Sw
 for pgsql-performance@arkaria.postgresql.org; Tue, 13 May 2014 20:34:14 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
 by malur.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <tim.kane@gmail.com>) id 1WkJOv-00078T-ED
 for pgsql-performance@postgresql.org; Tue, 13 May 2014 20:34:13 +0000
Received: from mail-wi0-x235.google.com ([2a00:1450:400c:c05::235])
 by magus.postgresql.org with esmtp (Exim 4.80)
 (envelope-from <tim.kane@gmail.com>) id 1WkJOr-0004qi-RW
 for pgsql-performance@postgresql.org; Tue, 13 May 2014 20:34:13 +0000
Received: by mail-wi0-f181.google.com with SMTP id n15so1298374wiw.8
 for <pgsql-performance@postgresql.org>; Tue, 13 May 2014 13:34:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=user-agent:date:subject:from:to:cc:message-id:thread-topic
 :references:in-reply-to:mime-version:content-type;
 bh=FD7+ZNsGWUM9uQXIV+XoaqjEhwR1TY73k3o5+7iVUDk=;
 b=tyGvfMCxtv86BrK4kXKcRcye8eqRp7lwdy7uBoM1P15bHyY4I3NaselyMAqOFE24/n
 VaUsf6iB9fSQxjqIKtfVyxTBpIQubXwm06xJ6rwh4vIRG5of9qEVg8LaS8tf8jLRe7f6
 n19ebFJx0abFNmIjvHjbrVZpwxShj+P6ukFjiA5WPQbB2fVYLpNlVCwj7r3hIcYzpDwV
 xGUduCcN+RS7+daCIH5V8oxTVZKU7nXeuH7ougRdY8BFlfrLgfEbQXqt7dPkd3rkXgNf
 gj4TKFjMz6+BWN/qfkUznh73HKcUUq/8tC/L6GsXBbDAba39LMWv/EKblXMLB/ejLoZ0
 Nbng==
X-Received: by 10.180.13.208 with SMTP id j16mr22424851wic.58.1400013249413;
 Tue, 13 May 2014 13:34:09 -0700 (PDT)
Received: from [192.168.0.28]
 (cpc14-dals19-2-0-cust193.20-2.cable.virginm.net. [62.31.88.194])
 by mx.google.com with ESMTPSA id fw13sm23764069wic.6.2014.05.13.13.34.04
 for <multiple recipients>
 (version=TLSv1 cipher=RC4-SHA bits=128/128);
 Tue, 13 May 2014 13:34:08 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/14.4.1.140326
Date: Tue, 13 May 2014 21:33:58 +0100
Subject: Re: Adaptive query execution
From: Tim Kane <tim.kane@gmail.com>
To: Claudio Freire <klaussfreire@gmail.com>
CC: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Message-ID: <CF983E13.7EFDD%tim.kane@gmail.com>
Thread-Topic: [PERFORM] Adaptive query execution
References: <CF983A39.7EF6F%tim.kane@gmail.com>
 <CAGTBQpY9+iYnkOeSYXDJ3V_VJnZczsXpgSbzF5BEjv9SpDvcnA@mail.gmail.com>
In-Reply-To: 
 <CAGTBQpY9+iYnkOeSYXDJ3V_VJnZczsXpgSbzF5BEjv9SpDvcnA@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative;
	boundary="B_3482861647_69747515"
X-Pg-Spam-Score: -2.0 (--)
List-Archive: <http://archives.postgresql.org/pgsql-performance>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-performance.postgresql.org>
List-Owner: <mailto:pgsql-performance-owner@postgresql.org>
List-Post: <mailto:pgsql-performance@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-performance>
List-Unsubscribe: 
 <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
X-Mailing-List: pgsql-performance
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3482861647_69747515
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

>=20
>=20
> From:  Claudio Freire <klaussfreire@gmail.com>
>>  I thought I would see what happens when I do this:
>>=20
>>    SELECT * FROM ONLY table_a UNION SELECT * FROM table_b;
>>=20
>>=20
>>=20
> What's the point, in the context of this example?
>=20
> The sort-unique still has to be performed even if you didn't have data
> in one side, since the other could still have duplicates.


Damn it. Okay, bad example. I should sleep.

A better example would be (from my other post just now -
http://www.postgresql.org/message-id/CF9838D8.7EF3D%tim.kane@gmail.com )
where an empty parent-table is append=E2=80=99ed into a result set involving one
(and only one) of its child relations.  Whereas a more optimum solution
would involve only the child relation without the need to append the empty
parent relation.

I=E2=80=99m sure there are other scenarios where adaptive query execution would b=
e
of greater benefit.

Tim







>=20



--B_3482861647_69747515
Content-type: text/html;
	charset="UTF-8"
Content-transfer-encoding: quoted-printable

<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size:=
 14px; font-family: Calibri, sans-serif;"><blockquote style=3D"margin:0 0 0 40=
px; border:none; padding:0px;"><div><br></div><div><br></div></blockquote><s=
pan id=3D"OLK_SRC_BODY_SECTION"><blockquote style=3D"margin:0 0 0 40px; border:n=
one; padding:0px;"><div style=3D"font-family:Calibri; font-size:11pt; text-ali=
gn:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; =
PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c=
4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style=3D"fon=
t-weight:bold">From: </span> Claudio Freire &lt;<a href=3D"mailto:klaussfreire=
@gmail.com">klaussfreire@gmail.com</a>&gt;<br></div></blockquote><div><div><=
blockquote style=3D"margin:0 0 0 40px; border:none; padding:0px;"><blockquote =
id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT: #b5c4df 5 solid;=
 PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> I thought I would see what happens =
when I do this:</div><div><br></div><div>&nbsp;&nbsp; SELECT * FROM ONLY tab=
le_a UNION SELECT * FROM table_b;</div><div><br></div><div><br></div><div><b=
r></div></blockquote><div>What's the point, in the context of this example?<=
/div><div><br></div><div>The sort-unique still has to be performed even if y=
ou didn't have data</div><div>in one side, since the other could still have =
duplicates.</div></blockquote></div></div></span><div><br></div><div><br></d=
iv><div>Damn it. Okay, bad example. I should sleep.</div><div><br></div><div=
>A better example would be (from my other post just now - <a href=3D"http://ww=
w.postgresql.org/message-id/CF9838D8.7EF3D%tim.kane@gmail.com">http://www.po=
stgresql.org/message-id/CF9838D8.7EF3D%tim.kane@gmail.com</a> ) where an emp=
ty parent-table is <i>append</i>&#8217;ed into a result set involving one (a=
nd only one) of its child relations. &nbsp;Whereas a more optimum solution w=
ould involve only the child relation without the need to <i>append</i>&nbsp;=
the empty parent relation.</div><div><br></div><div>I&#8217;m sure there are=
 other scenarios where adaptive query execution would be of greater benefit.=
</div><div><br></div><div>Tim</div><div><br></div><div><br></div><div><br></=
div><div><br></div><div><br></div><div><br></div><div><br></div><span id=3D"OL=
K_SRC_BODY_SECTION"><div><div><blockquote style=3D"margin:0 0 0 40px; border:n=
one; padding:0px;"><div><br></div></blockquote></div></div></span></body></h=
tml>

--B_3482861647_69747515--