Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WkJ00-0005sN-O5 for pgsql-performance@arkaria.postgresql.org; Tue, 13 May 2014 20:08:28 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1WkJ00-0004Ic-2r for pgsql-performance@arkaria.postgresql.org; Tue, 13 May 2014 20:08:28 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WkIzy-0004IV-Pi for pgsql-performance@postgresql.org; Tue, 13 May 2014 20:08:26 +0000 Received: from mail-wi0-x22e.google.com ([2a00:1450:400c:c05::22e]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1WkIzv-0005Ph-N5 for pgsql-performance@postgresql.org; Tue, 13 May 2014 20:08:25 +0000 Received: by mail-wi0-f174.google.com with SMTP id r20so6894734wiv.13 for ; Tue, 13 May 2014 13:08:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=EOtdAFiNpWk3roySpR80Ley+ma0BfoMVLhygTVg5Ksw=; b=mNQATFCGjwC4Kk63BbR/U/z+O1Fn+vJh30p2Zq7We8scLh4nJN3GWjxCFJ1bUPlXsd HRo2dVdezRqS6lkmBzqKkzNyiiArqT2EFJAI6WNICQsEduDv0c717IrEa1qkynaGtY7A PggLuecFK+nP5J9zK2yVhVfUQde9lLr9Pgoq+zMqPhsOQKKG/EtRWNmetY1/YZPYc+9h neNAXbAep6hceRmdea9oXYp6sx/Ae5KeGzkvriEJBLdmDlOognHS999HTJfLNAuM9P8u UVOk731hCGikO5r6I5GfJ8S+WuQjDGpQ0OTAgnRlMN1ew31G0e5rKeLOgfI5uRuTadPo K5EA== X-Received: by 10.180.11.178 with SMTP id r18mr22807645wib.41.1400011701052; Tue, 13 May 2014 13:08:21 -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 c7sm23494502wjf.19.2014.05.13.13.08.16 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 13 May 2014 13:08:20 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.4.1.140326 Date: Tue, 13 May 2014 21:08:09 +0100 Subject: Adaptive query execution From: Tim Kane To: "pgsql-performance@postgresql.org" Message-ID: Thread-Topic: Adaptive query execution Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3482860098_69660349" X-Pg-Spam-Score: -2.0 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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_3482860098_69660349 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi all, So I was thinking about the following, after experimenting with constraint exclusion. I thought I would see what happens when I do this: SELECT * FROM ONLY table_a UNION SELECT * FROM table_b; I noticed that despite table_a still having no data in it, the planner has already decided that it needs to insert a chain of =E2=80=98append->sort->unique= =E2=80=99 nodes into the plan. That=E2=80=99s fairly reasonable. While I understand that we can=E2=80=99t readily know about wether a given node w= ill return anything or not - would it be possible to have the execution engine branch off in the event that a given node returns nothing at all? I guess there are probably a lot of considerations, and I suspect it would considerably increase planning time, though maybe it also presents an opportunity for some interesting approaches to adaptive query execution. I don=E2=80=99t know so much about this, though I=E2=80=99m sure there are all kinds of research papers discussing it. Is this something that has been considered before? Tim --B_3482860098_69660349 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi all,

So I was thinking about the following, after experim= enting with constraint exclusion.

I thought I = would see what happens when I do this:

  SELECT * FROM ONLY table_a UNION SELECT * FROM table_b;


I noticed that despite t= able_a still having no data in it, the planner has already decided = that it needs to insert a chain of  ‘append->sort->unique&#= 8217;  nodes into the plan.

That’s fairl= y reasonable.
While I understand that we can’t readily know = about wether a given node will return anything or not - would it be possible= to have the execution engine branch off in the event that a given node retu= rns nothing at all?

I guess there are probably a lo= t of considerations, and I suspect it would considerably increase planning t= ime, though maybe it also presents an opportunity for some interesting appro= aches to adaptive query execution.

I do= n’t know so much about this, though I’m sure there are all kinds= of research papers discussing it.
Is this something that has been= considered before?

Tim

= --B_3482860098_69660349--