Re: PG 18 release notes draft committed - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: PG 18 release notes draft committed
Date
Msg-id CAAKRu_bqjgSYA+OdemL-X91Yv53OwsVARZy+-tRyj8YQ=kcj0A@mail.gmail.com
Whole thread Raw
In response to PG 18 release notes draft committed  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Wed, May 28, 2025 at 10:49 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> On Wed, May 28, 2025 at 08:07:20PM -0400, Melanie Plageman wrote:
>
> Yes, I can now see it is two items so I have split it into two in the
> attached, applied patch.  In a separate commit I adjusted the docs for
> log_connections to more clearly explain the new "setup_durations"
> output.

Cool, thanks!

> > "Add an asynchronous I/O subsystem"
> >
> > I notice we don't call out any of the operations where users could
> > expect to see asynchronous IO be used. Some were enabled in 17 (like
> > sequential scans, analyze, and pg_prewarm), but most of the read
> > stream users went in this release:
> >
> > d9c7911e1a5, 043799fa08c, e215166c9c8, 69273b818b1, c5c239e26e3,
> > 2b73a8cd33b, 9256822608f, c3e775e608f, 8720a15e9ab12, 65c310b310a
> >
> > I have had users ask me already which operations they can expect to
> > use asynchronous I/O. The most commonly encountered AIO operations are
> > probably be vacuum, bitmap heap scan, and sequential scans, but it
> > might be worth having a list somewhere of what uses AIO. I expect
> > we'll get the question quite often.
>
> Yes, I knew I needed more detail on this.  I have added text in this
> commit to try to improve that.

Maybe it is worth saying something at the end like "amongst other
operations" to clarify it isn't just those.
I noticed in the PG 17 release notes [1] we did include the shas of
each of the commits for the read stream users. Should we do that here
as well? Those are what enable those operations to use AIO.

> > "Allow specification of the fixed number of dead tuples that will
> > trigger an autovacuum"
> >
> > We also added a kind of corollary for insert-triggered vacuums in
> > 06eae9e6218ab2a which attempts to deal with a similar problem of big
> > tables not being autovacuumed enough but for insert-mostly tables.
> > Perhaps because there is no exposed configuration it is not worth
> > mentioning, but I thought I would bring it up since their purposes are
> > related.
>
> I studied this and I can't figure out how to clearly explain it in a
> useful way.  I am now thinking it is more of a bug or behavior fix or
> that would not be usually mentioned.

 Makes sense

- Melanie

[1] https://www.postgresql.org/docs/current/release-17.html



pgsql-hackers by date:

Previous
From: Timur Magomedov
Date:
Subject: Re: [WIP]Vertical Clustered Index (columnar store extension) - take2
Next
From: Robert Haas
Date:
Subject: Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them