On Tue, Nov 3, 2015 at 12:33 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Tue, Nov 3, 2015 at 5:04 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> On Sat, Oct 31, 2015 at 1:32 AM, Amit Kapila <amit.kapila16@gmail.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.
>
In that case, file suffix would be "_pim" or "_psm"?
IMO, "page info map" would be better, because the bit doesn't indicate
the status of page in real time, it's just additional information.
Also we need to rewrite to new name in source code, and source file
name as well.
Regards,
--
Masahiko Sawada