Re: PG 10 release notes

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG 10 release notes
Date: 2017-04-25 13:49:01
Message-ID: 20170425134901.GH7513@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 25, 2017 at 09:00:45AM +0530, Amit Kapila wrote:
> On Tue, Apr 25, 2017 at 8:35 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > On Tue, Apr 25, 2017 at 08:30:50AM +0530, Amit Kapila wrote:
> >> On Tue, Apr 25, 2017 at 7:01 AM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> >> > I have committed the first draft of the Postgres 10 release notes. They
> >> > are current as of two days ago, and I will keep them current. Please
> >> > give me any feedback you have.
> >> >
> >>
> >> Some of the items which I feel could be added:
> >>
> >> 5e6d8d2bbbcace304450b309e79366c0da4063e4
> >> Allow parallel workers to execute subplans.
> >
> > Uh, can you show me the commit on that and give some text ideas?
> >
>
> I have already mentioned the commit id (5e6d8d2b). Text can be "Allow
> queries containing subplans to execute in parallel". We should also
> mention in some way that this applies only when the query contains
> uncorrelated subplan.

Sorry but I don't know what that means, and if I don't know, others
might not either.

> >> 61c2e1a95f94bb904953a6281ce17a18ac38ee6d
> >> Improve access to parallel query from procedural languages.
> >
> > I think I have that:
> >
> > Increase parallel query usage in procedural language functions (Robert
> > Haas)
> >
> >> In Parallel Queries section, we can add above two items as they
> >> increase the usage of the parallel query in many cases.
> >>
> >> ea69a0dead5128c421140dc53fac165ba4af8520
> >> Expand hash indexes more gradually.
> >
> > That is in this item:
> >
> > Improve hash bucket split performance by reducing locking requirements
> > (Amit Kapila, Mithun Cy)
> >
> > Also cache hash index meta-information for faster lookups. Additional
> > hash performance improvements have also been made. pg_upgrade'd hash
> > indexes from previous major Postgres versions must be rebuilt.
> >
> > Can you suggest additional wording?
> >
>
> Allow hash indexes to expand slowly
>
> This will help in controlling the size of hash indexes after the split.

OK, I split out the "growth" item into a separate item and moved the
hash items into a separate section now that there are enough of them to
warrant it.

> > I did merge many of the hash items
> > into this so it would be understandable. You can see the commits in the
> > SGML source.
> >
> >> I think the above commit needs a separate mention, as this is a really
> >> huge step forward to control the size of hash indexes.
> >
> > Yes, it is unfotunate that the item is in the incompatibility item. I
> > wonder if I should split out the need to rebuild the hash indexes and
> > keep it there and move this item into the "Index" section.
> >
>
> That sounds sensible.

Yes, already done.

Again, the most current doc build is here:

http://momjian.us/pgsql_docs/release-10.html

--
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-hackers by date

  From Date Subject
Next Message Bruce Momjian 2017-04-25 14:00:04 Re: PG 10 release notes
Previous Message K S, Sandhya (Nokia - IN/Bangalore) 2017-04-25 13:44:49 Re: Crash observed during the start of the Postgres process