Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hS0Ir-0006Kz-BC for pgsql-advocacy@arkaria.postgresql.org; Sat, 18 May 2019 14:27:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hS0In-0004VX-Gq for pgsql-advocacy@arkaria.postgresql.org; Sat, 18 May 2019 14:27:09 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hS0Im-0004VP-Sv for pgsql-advocacy@lists.postgresql.org; Sat, 18 May 2019 14:27:09 +0000 Received: from mail-it1-x142.google.com ([2607:f8b0:4864:20::142]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hS0If-0004eD-F5 for pgsql-advocacy@lists.postgresql.org; Sat, 18 May 2019 14:27:07 +0000 Received: by mail-it1-x142.google.com with SMTP id m141so16378466ita.3 for ; Sat, 18 May 2019 07:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wp0jj/M4qD7G3laht4WRB9+fslCZ1sQu+wp6h1jOUlE=; b=lxsjxzP4f5BIlwV+NsDUh0E3Eyj6Y1+yTLLTX6+xLzoJDApk9FKdg4vE/TqFy+pcKJ BZOTWAXpydQhcWC1IQQwQNsoPCLcm7P5RGBD8gsaDOj1NysB+Ti6gNqwfi+tJ+8k+BzU XiDXdpfrO1/e0vX+MnM74b4yCKcXqKOWfDxXvpFnRxR5COswPoDynol/cjHDBDHn35bI drGEEld3Gpg4/RAES5mNfQ8vage/9hpGVdwuwim5QTUZnSxNpIwSSMdciDYWBYYXD/W3 m5YJjA9JRzAMv/VTz9/0uxNE6aw1NYvu5Dy1yBZ6ZumiLP8/HG5KSIusjH8zuh2LCi2S TeJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Wp0jj/M4qD7G3laht4WRB9+fslCZ1sQu+wp6h1jOUlE=; b=XdZRzFYqM+eDyNhkU3UHjh8YHVBPgr4O79j1L0JuLcvxo01TnlXlgna0+jayJp50s2 fyKzvViPIoa9kwAJvGV1Po+an5NUqIL1fuVUMzenJ28GFEb97n3z3pP/fBhujZpOQYBN JOzz9GWAvxuP1RfKSgmSw49b3z26Uyk4jBz5Wcd5G+fEgseeVjrQPd2yCUD8kCwbdznZ VvqUZCZm8KnrEVIKalWy5PLxciZO6dQPo22ceAIcsVon7hFvdPkSGnoQhQaFl+pkZEg0 F1I2mdndpm4oQh2ljHLRXvpQ0iaDK2Qh6s9YY9UB6W5erj7WbzAOPDKrIBBAr9p7Awcy kXTA== X-Gm-Message-State: APjAAAXTB4Z5dJv4mdo31oZvUGSLQUjxp86ElHpbFs51zZa8H12lB2+a ij5HRTKWe90cj5DUIItR45rkyN0tK2zpHky9XdRv9w== X-Google-Smtp-Source: APXvYqwCoRnWoKnGzZ5q0XdEOS/NPuDC+/SxDMVsakijjp6Fe/1/Q1sb95iQTgaF23W49noUeku+Y+VPsByM384dw74= X-Received: by 2002:a02:4049:: with SMTP id n70mr41545088jaa.42.1558189620151; Sat, 18 May 2019 07:27:00 -0700 (PDT) MIME-Version: 1.0 References: <20190516182628.kbkiajfnlooocgyg@momjian.us> <0cf10a27-c6a0-de4a-cd20-ab7493ea7422@lab.ntt.co.jp> <20190517153653.pmolnulev6imwsn3@momjian.us> <20190518023017.nkucoc5xgoebtvfw@momjian.us> <20190518132031.zjyxgvys7unan53f@momjian.us> In-Reply-To: <20190518132031.zjyxgvys7unan53f@momjian.us> From: David Rowley Date: Sun, 19 May 2019 02:26:48 +1200 Message-ID: Subject: Re: PostgreSQL 12: Feature Highlights To: Bruce Momjian Cc: Amit Langote , "Jonathan S. Katz" , pgsql-advocacy@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, 19 May 2019 at 01:20, Bruce Momjian wrote: > The first one needs to reference visible effects, so I would add: > > Consider additional optimizations for queries referencing > partitioned tables that only affect a single partition > > Does that work? Thanks, typing that up. I think it lacks a bit detail about what's actually changed. The change is fairly evident and people can see when it takes effect when they look at EXPLAIN and see that the Append/MergeAppend node is missing. Also, an Append/MergeAppend may exist for inheritance tables and an Append can exist for a simple UNION ALL. Both of those cases can have subplans removed to leave only a single subplan, to which the additional parallel paths will be considered. I think something like: * Make the optimizer only include an Append/MergeAppend node when there is more than one subplan to append. This reduces execution overheads and allows additional plan shapes that were previously not possible. or a little more brief: * Allow the optimizer to consider more plan types by eliminating single subplan Append and MergeAppends. I understand that you might be trying to avoid details of plan node types, but really anyone who's got inheritance or partitioned tables and has looked at an EXPLAIN should have an idea. Also, I think Tom should be the main author of this as he rewrote my version of the patch to such an extent that there was next to nothing of it left. I just tagged a few extra things on before he committed it. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services