Re: Freeze avoidance of very large table.

Поиск
Список
Период
Сортировка
От Sawada Masahiko
Тема Re: Freeze avoidance of very large table.
Дата
Msg-id CAD21AoA9KD-pQtcNdr7HFSf_droT_sWqSTgU4KKnVBUFbOVFNg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Freeze avoidance of very large table.  (Andres Freund <andres@anarazel.de>)
Ответы Re: Freeze avoidance of very large table.  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Freeze avoidance of very large table.  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Mon, Jul 13, 2015 at 9:22 PM, Andres Freund <andres@anarazel.de> wrote:
> 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.

Ah, If we set all bit as not all-frozen,  we don't need to whole table
scanning, only scan vm.
And I agree with this.

But please image the case where old cluster has table which is very
large, read-only and vacuum freeze is done.
In this case, the all-frozen bit of such table in new cluster will not
set, unless we do vacuum freeze again.
The information of all-frozen of such table is lacked.

Regards,

--
Masahiko Sawada



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ryan Pedela
Дата:
Сообщение: Re: [PATCH] Generalized JSON output functions
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: [PATCH] Generalized JSON output functions