| From: | Melanie Plageman <melanieplageman(at)gmail(dot)com> | 
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> | 
| Cc: | PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org> | 
| Subject: | Re: PG 18 release notes draft committed | 
| Date: | 2025-05-29 13:42:30 | 
| Message-ID: | CAAKRu_bqjgSYA+OdemL-X91Yv53OwsVARZy+-tRyj8YQ=kcj0A@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Wed, May 28, 2025 at 10:49 PM Bruce Momjian <bruce(at)momjian(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2025-05-29 13:43:41 | Re: pg18: Virtual generated columns are not (yet) safe when superuser selects from them | 
| Previous Message | Timur Magomedov | 2025-05-29 13:30:23 | Re: [WIP]Vertical Clustered Index (columnar store extension) - take2 |