Re: Freeze avoidance of very large table. - Mailing list pgsql-hackers

From Thom Brown
Subject Re: Freeze avoidance of very large table.
Date
Msg-id CAA-aLv7EsxyXDoTbQwMXV9UKGYMGkta_G8sDmSEkvD7iTLGF+w@mail.gmail.com
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Freeze avoidance of very large table.  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
On 17 November 2015 at 10:29, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
>
> On Tue, Nov 17, 2015 at 10:45 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Sun, Nov 15, 2015 at 1:47 AM, Amit Kapila <amit.kapila16@gmail.com>
>> wrote:
>>> On Sat, Nov 14, 2015 at 1:19 AM, Andres Freund <andres@anarazel.de>
>>> wrote:
>>>> On 2015-10-31 11:02:12 +0530, Amit Kapila wrote:
>>>> > 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?
>>>>
>>>> Several:
>>>> * Visibility map is rather descriptive, none of the replacement terms
>>>>   imo come close. Few people will know what a 'freeze' map is.
>>>> * It increases the size of the patch considerably
>>>> * It forces tooling that knows about the layout of the database
>>>>   directory to change their tools
>>>>
>>>
>>> All these points are legitimate.
>>>
>>>> On the benfit side the only argument I've heard so far is that it allows
>>>> to disambiguate the format. But, uh, a look at the major version does
>>>> that just as well, for far less trouble.
>>>>
>>>> > 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.
>>>>
>>>> Being frozen is about visibility as well.
>>>>
>>>
>>> OTOH being visible doesn't mean page is frozen.  I understand that frozen
>>> is
>>> related to visibility, but still it is a separate state of page and used
>>> for
>>> different
>>> purpose.  I think this is a subjective point and we could go either way,
>>> it
>>> is
>>> just a matter in which way more people are comfortable.
>>
>> I'm stickin' with what I said before, and what I think Andres is
>> saying too: renaming the map is a horrible idea.  It produces lots of
>> code churn for no real benefit.  We usually avoid such changes, and I
>> think we should do so here, too.
>
> I understood.
> I'm going to turn the patch back to visibility map, and just add the logic
> of enhancement of VACUUM FREEZE.
> If we want to add the other status not related to visibility into visibility
> map in the future, it would be worth to consider.

Could someone post a TL;DR summary of what the current plan looks
like?  I can see there is a huge amount of discussion to trawl back
through.  I can see it's something to do with the visibility map.  And
does it avoid freezing very large tables like the title originally
sought?

Thanks

Thom



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Support for N synchronous standby servers - take 2
Next
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Support for N synchronous standby servers - take 2