Re: PostgreSQL 12: Feature Highlights

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, pgsql-advocacy(at)lists(dot)postgresql(dot)org
Subject: Re: PostgreSQL 12: Feature Highlights
Date: 2019-05-21 14:55:09
Message-ID: 20190521145509.s6bme6pgww3glmku@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-advocacy pgsql-hackers

On Sun, May 19, 2019 at 02:26:48AM +1200, David Rowley wrote:
> On Sun, 19 May 2019 at 01:20, Bruce Momjian <bruce(at)momjian(dot)us> 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 <bruce(at)momjian(dot)us> 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 +

In response to

Responses

Browse pgsql-advocacy by date

  From Date Subject
Next Message Amit Langote 2019-05-22 00:23:13 Re: PostgreSQL 12: Feature Highlights
Previous Message Amit Langote 2019-05-21 00:47:54 Re: PostgreSQL 12: Feature Highlights

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-05-21 15:19:59 Re: VACUUM fails to parse 0 and 1 as boolean value
Previous Message Antonin Houska 2019-05-21 14:47:50 Re: A few more opportunities to use TupleTableSlotOps fields