Re: PG 14 release notes, first draft

On Mon, 10 May 2021 at 19:34, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> On Mon, May 10, 2021 at 01:44:12PM +0200, Matthias van de Meent wrote:
> > On Mon, 10 May 2021 at 08:03, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > >
> > > I have committed the first draft of the PG 14 release notes. You can
> > > see the most current build of them here:
> > > https://momjian.us/pgsql_docs/release-14.html
> > >
> > > I need clarification on many items, and the document still needs its
> > > items properly ordered, and markup added. I also expect a lot of
> > > feedback.
> >
> > I noticed that the improvement in bloat control in the HeapAM that I
> > know of (3c3b8a4b, 0ff8bbde) weren't documented here. Although each
> > can be considered minor, they together can decrease the bloating
> > behaviour of certain workloads significantly (and limit the total
> > damage), and in my opinion this should be mentioned.
> >
> > 3c3b8a4b: Returns space claimed for the line pointer array back to the
> > page's empty space, so that it can also be used for tuple data.
> >
> > 0ff8bbde: Allows large tuples to be inserted on pages which have only
> > a small amount of data, regardless of fillfactor.
> >
> > Together they should be able to help significantly in both bloat
> > prevention and bloat reduction.
>
> I looked at those items. I try to mention performance items that enable
> new workloads or require some user action to benefit from it.

0ff8bbde Enables a workload that inserts (and non-locally updates)
large (> FILLFACTOR %) tuples in tables that have a low FILLFACTOR.
Previously this would fail dramatically by only inserting on new
pages; this would extend the table indefinately. See the thread [0]

3c3b8a4b improves workloads with high local update-then-delete churn.
Previously this would irreversably claim space on the page for tuple
identifiers even when they were later deleted; now we can reclaim this
space when a tuple is deleted from the page.

I see these two improvements in a similar light as the bottom-up index
deletion in btree: No user action required, works out-of-the-box,
decreases bloat / disk usage, but good to note as it fixes (known)
bloating footguns that a user might have encountered.

> I am not sure these two qualify, but can others comments? Thanks.

I'd like to refer to Peter Geoghegan's reply [1] upthread.

Thank you for your effort,

Matthias van de Meent

[0] https://www.postgresql.org/message-id/flat/6e263217180649339720afe2176c50aa%40opammb0562.comp.optiver.com
[1] https://www.postgresql.org/message-id/CAH2-Wz%3D-A%3DjRxpB2Owj3KQadCue7%2BNLqj56Q566ees7TapMRvA%40mail.gmail.com