Re: PG 10 release notes

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.

>> 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.

> 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.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com