Re: Reviewing freeze map code

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Victor Yegorov <vyegorov(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reviewing freeze map code
Date: 2016-05-18 15:52:38
Message-ID: CAMkU=1ygHztvjr-hS3RRLyYmEdZkTDrwf5Cjch4xa5HLcpZRDQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 18, 2016 at 7:09 AM, Joe Conway <mail(at)joeconway(dot)com> wrote:
> On 05/18/2016 09:55 AM, Victor Yegorov wrote:
>> 2016-05-18 16:45 GMT+03:00 Robert Haas <robertmhaas(at)gmail(dot)com
>> <mailto:robertmhaas(at)gmail(dot)com>>:
>>
>> No, that's what the existing FREEZE option does. This new option is
>> about unnecessarily vacuuming pages that don't need it. The
>> expectation is that vacuuming all-frozen pages will be a no-op.
>>
>>
>> VACUUM (INCLUDING ALL) ?
>
> VACUUM (FORCE ALL) ?

How about going with something that says more about why we are doing
it, rather than trying to describe in one or two words what it is
doing?

VACUUM (FORENSIC)

VACUUM (DEBUG)

VACUUM (LINT)

Cheers,

Jeff

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message chang chao 2016-05-18 16:01:59 explain analyze does not report actual rows correctly?
Previous Message chang chao 2016-05-18 15:42:15 Re: The rewritting of join conditions caused a very slow query plan.