Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)
| От | Andres Freund |
|---|---|
| Тема | Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs) |
| Дата | |
| Msg-id | 20220707000446.hefgyu5xikxwt4md@alap3.anarazel.de обсуждение исходный текст |
| Ответ на | Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs) (Nitin Jadhav <nitinjadhavpostgres@gmail.com>) |
| Ответы |
Re: Report checkpoint progress with pg_stat_progress_checkpoint (was: Report checkpoint progress in server logs)
|
| Список | pgsql-hackers |
Hi, On 2022-06-13 19:08:35 +0530, Nitin Jadhav wrote: > > Have you measured the performance effects of this? On fast storage with large > > shared_buffers I've seen these loops in profiles. It's probably fine, but it'd > > be good to verify that. > > To understand the performance effects of the above, I have taken the > average of five checkpoints with the patch and without the patch in my > environment. Here are the results. > With patch: 269.65 s > Without patch: 269.60 s Those look like timed checkpoints - if the checkpoints are sleeping a part of the time, you're not going to see any potential overhead. To see whether this has an effect you'd have to make sure there's a certain number of dirty buffers (e.g. by doing CREATE TABLE AS some_query) and then do a manual checkpoint and time how long that times. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: