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.
|
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: