Re: PG 18 release notes draft committed
От | Melanie Plageman |
---|---|
Тема | Re: PG 18 release notes draft committed |
Дата | |
Msg-id | CAAKRu_bqjgSYA+OdemL-X91Yv53OwsVARZy+-tRyj8YQ=kcj0A@mail.gmail.com обсуждение исходный текст |
Ответ на | PG 18 release notes draft committed (Bruce Momjian <bruce@momjian.us>) |
Список | 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 по дате отправления: