Re: [HACKERS] PG 10 release notes

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@momjian.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@momjian.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@momjian.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 +