Re: add --no-sync to pg_upgrade's calls to pg_dump and pg_dumpall
В списке pgsql-hackers по дате отправления:
| От | Nathan Bossart |
|---|---|
| Тема | Re: add --no-sync to pg_upgrade's calls to pg_dump and pg_dumpall |
| Дата | |
| Msg-id | 20240509193425.GA3219615@nathanxps13 обсуждение исходный текст |
| Ответ на | Re: add --no-sync to pg_upgrade's calls to pg_dump and pg_dumpall (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: add --no-sync to pg_upgrade's calls to pg_dump and pg_dumpall
|
| Список | pgsql-hackers |
On Thu, May 09, 2024 at 09:03:56AM +0900, Michael Paquier wrote: > +1. Could there be an argument in favor of a backpatch? This is a > performance improvement, but one could also side that the addition of > sync support in pg_dump[all] has made that a regression that we'd > better fix because the flushes don't matter in this context. They > also bring costs for no gain. I don't see a strong need to back-patch this, if for no other reason than it seems to have gone unnoticed for 7 major versions. Plus, based on my admittedly limited testing, this is unlikely to provide significant improvements. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера