Re: Freeze avoidance of very large table.

On Tue, Nov 3, 2015 at 5:04 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Sat, Oct 31, 2015 at 1:32 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> >
> > What is your main worry about changing the name of this map, is it
> > about more code churn or is it about that we might introduce new issues
> > or is it about that people are already accustomed to call this map as
> > visibility map?
>
> My concern is mostly that I think calling it the "visibility and
> freeze map" is excessively long and wordy.
>
> One observation that someone made previously is that there is a
> difference between "all-visible" and "index-only scan OK". An
> all-visible page that has a HOT update is no longer all-visible (it
> needs vacuuming) but an index-only scan would still be OK (because
> only the non-indexed values in the tuple have changed, and every scan
> scan can see either the old or the new tuple but not both. At
> present, the index-only scan will consult the heap page anyway,
> because all we know is that the page is not all-visible. But maybe in
> the future somebody will decide to add a bit for that. Then we'd have
> the "visibility, usable for index-only scans, and freeze map", but I
> think "_vufiosfm" will not be a good choice for a file suffix.
>

I think in that case we can call it as page info map or page state map, but
I find retaining visibility map name in this case or for future (if we want
to
add another bit) as confusing. In-fact if you find "visibility and freeze
map",
as excessively long, then we can change it to "page info map" or "page state
map" now as well.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com