Re: Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits - Mailing list pgsql-hackers

From David Steele
Subject Re: Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits
Date
Msg-id ff4c55c4-ac5b-e709-87c2-915cf14221f3@pgmasters.net
Whole thread Raw
In response to Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
Hi Pavan,

On 3/14/19 2:20 PM, Masahiko Sawada wrote:
> On Thu, Mar 14, 2019 at 5:17 PM Pavan Deolasee <pavan.deolasee@gmail.com> wrote:
>>
>> Ok. I will run some tests. But please note that this patch is a bug fix to address the performance issue that is
causedby having to rewrite the entire table when all-visible bit is set on the page during first vacuum. So while we
maydo some more work during COPY FREEZE, we're saving a lot of page writes during next vacuum. Also, since the scan
thatwe are doing in this patch is done on a page that should be in the buffer cache, we will pay a bit in terms of CPU
cost,but not anything in terms of IO cost.
 
> 
> Agreed. I had been misunderstanding this patch. The page scan during
> COPY FREEZE is necessary and it's very cheaper than doing in the first
> vacuum.

I have removed Ibrar as a reviewer since there has been no review from 
them in three weeks, and too encourage others to have a look.

Regards,
-- 
-David
david@pgmasters.net


pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Re: Reporting script runtimes in pg_regress
Next
From: David Steele
Date:
Subject: Re: Re: [RFC] [PATCH] Flexible "partition pruning" hook