| От | Andres Freund |
|---|---|
| Тема | Re: Freeze avoidance of very large table. |
| Дата | |
| Msg-id | 20150713122250.GA9518@awork2.anarazel.de обсуждение |
| Ответ на | Re: Freeze avoidance of very large table. (Sawada Masahiko <sawada.mshk@gmail.com>) |
| Ответы |
Re: Freeze avoidance of very large table.
|
| Список | pgsql-hackers |
On 2015-07-13 21:03:07 +0900, Sawada Masahiko wrote: > Even If we implement rewriting tool for vm into pg_upgrade, it will > take time as much as revacuum because it need whole scanning table. Why would it? Sure, you can only set allvisible and not the frozen bit, but that's fine. That way the cost for freezing can be paid over time. If we require terrabytes of data to be scanned, including possibly rewriting large portions due to freezing, before index only scans work and most vacuums act in a partial manner the migration to 9.6 will be a major pain for our users.
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера