public inbox for [email protected]
help / color / mirror / Atom feedFrom: Bruce Momjian <[email protected]>
To: David Rowley <[email protected]>
Cc: Amit Langote <[email protected]>
Cc: Jonathan S. Katz <[email protected]>
Cc: [email protected]
Subject: Re: PostgreSQL 12: Feature Highlights
Date: Tue, 21 May 2019 10:55:09 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAKJS1f9TVMvGQdwxMemci34viPZuiLTFOJa4rc1Bfhm57WycFA@mail.gmail.com>
References: <CAKJS1f-pCFYGq1-go+ZyAR3GisQo-nTD=7E8ykk7Zqm9w+-OkA@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAKJS1f_c8tngWJZjNcQY0KXHWVs4JZxyzoX_cGBEHbaWKUAC=w@mail.gmail.com>
<[email protected]>
<CAKJS1f8R8riwBXw==7ijV=UZNuhP+3qXgDBKSiM+=_cTf4mXXw@mail.gmail.com>
<[email protected]>
<CAKJS1f9TVMvGQdwxMemci34viPZuiLTFOJa4rc1Bfhm57WycFA@mail.gmail.com>
On Sun, May 19, 2019 at 02:26:48AM +1200, David Rowley wrote:
> On Sun, 19 May 2019 at 01:20, Bruce Momjian <[email protected]> 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.
This brings up a few points. First, it seems the change affects
partitioned tables and UNION ALL, which means it probably needs to be
listed in two sections. Second, is it only parallelism paths that are
added? I am not sure if people care about a node being removed,
especially when the might not even know we do that step, but they do
care if there are new optimization possibilities.
> 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.
I would like to have something that people who don't study EXPLAIN will
still be excited about.
> 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.
Uh, Tom listed you as author, but I don't have to follow that if you
feel it is inaccurate.
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
view thread (63+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: PostgreSQL 12: Feature Highlights
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox