From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Subject: | Re: Summary of plans to avoid the annoyance of Freezing |
Date: | 2015-09-15 09:24:03 |
Message-ID: | CAD21AoD5qPgdiK4Zem18zoat8s7v8nuWTvmQbEznOuj1ZiAPZQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 9, 2015 at 10:03 PM, Greg Stark <stark(at)mit(dot)edu> wrote:
> On Sun, Sep 6, 2015 at 1:25 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> My vote is that we should try to get freeze maps into 9.6 - that seems
>> more realistic given that we have a patch right now. Yes, it might end
>> up being superflous churn, but it's rather localized. I think around
>> we've put off significant incremental improvements off with the promise
>> of more radical stuff too often.
>
> Superfluous churn in the code isn't too bad. But superfluous churn in
> data formats might be a bit more scary. Would we be able to handle
> pg_upgrade from a database with or without a freezemap? Would you have
> to upgrade once to add the freezemap then again to remove it?
>
Currently freeze map patch adds frozen bit to visibility map when
upgrading to 9.6.
The visibility map is not critical information, and is generated by VACUUM.
So we can drop it and create new visibility map by doing VACUUM, if
table size is not large.
Regards,
--
Masahiko Sawada
From | Date | Subject | |
---|---|---|---|
Next Message | YUriy Zhuravlev | 2015-09-15 09:51:24 | Re: Move PinBuffer and UnpinBuffer to atomics |
Previous Message | David Rowley | 2015-09-15 09:18:56 | Re: [PROPOSAL] Covering + unique indexes. |