| From: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
|---|---|
| To: | "'Bossart, Nathan'" <bossartn(at)amazon(dot)com> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | RE: A few new options for CHECKPOINT |
| Date: | 2020-11-25 00:03:31 |
| Message-ID: | TYAPR01MB2990F066EC4B13B37120C6F3FEFA0@TYAPR01MB2990.jpnprd01.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: Bossart, Nathan <bossartn(at)amazon(dot)com>
> The main purpose of this patch is to give users more control over their manually
> requested checkpoints or restartpoints. I suspect the most useful option is
> IMMEDIATE, which can help avoid checkpoint- related IO spikes. However, I
> didn't see any strong reason to prevent users from also adjusting FORCE and
> WAIT.
I think just IMMEDIATE would suffice, too. But could you tell us why you got to want to give users more control? Could we know concrete example situations where users want to perform CHECKPOINT with options?
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andy Fan | 2020-11-25 00:10:21 | Re: About adding a new filed to a struct in primnodes.h |
| Previous Message | David Zhang | 2020-11-24 23:32:38 | Add table access method as an option to pgbench |