Re: Freeze avoidance of very large table.

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Freeze avoidance of very large table.
Дата
Msg-id CAA4eK1+0sN15TmmZxWqCKsQvdeOqXxoCPLuiUaT5HnjRJFKgEQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Freeze avoidance of very large table.  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Freeze avoidance of very large table.  (Robert Haas <robertmhaas@gmail.com>)
Re: Freeze avoidance of very large table.  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Thu, Oct 8, 2015 at 11:05 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
> On 1 October 2015 at 23:30, Josh Berkus <josh@agliodbs.com> wrote:
>>
>> On 10/01/2015 07:43 AM, Robert Haas wrote:
>> > On Thu, Oct 1, 2015 at 9:44 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> >> I wonder how much it's worth renaming only the file extension while
>> >> there are many places where "visibility map" and "vm" are used,
>> >> for example, log messages, function names, variables, etc.
>> >
>> > I'd be inclined to keep calling it the visibility map (vm) even if it
>> > also contains freeze information.
>> >

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?

>>
>> -1 to rename.  Visibility Map is a perfectly good name.
>
>
> The name can stay the same, but specifically the file extension should change.
>

It seems to me quite logical for understanding purpose as well.  Any new
person who wants to work in this area or is looking into it will always
wonder why this map is named as visibility map even though it contains
information about visibility of page as well as frozen state of page.  So
even though it doesn't make any difference in correctness of feature whether
we retain the current name or change it to Visibility & Freeze Map (aka vfm),
but I think it makes sense to change it for the sake of maintenance of this
code.


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

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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: September 2015 Commitfest