On Mon, 10 May 2021 at 19:34, Bruce Momjian <br...@momjian.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 <br...@momjian.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
