Re: Removing PD_ALL_VISIBLE - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Removing PD_ALL_VISIBLE
Date
Msg-id 50F8153C.6020300@vmware.com
Whole thread Raw
In response to Re: Removing PD_ALL_VISIBLE  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Removing PD_ALL_VISIBLE  (Simon Riggs <simon@2ndQuadrant.com>)
Re: Removing PD_ALL_VISIBLE  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On 17.01.2013 16:53, Robert Haas wrote:
> On Thu, Jan 17, 2013 at 3:49 AM, Pavan Deolasee
> <pavan.deolasee@gmail.com>  wrote:
>> May be you've already addressed that concern with the proven
>> performance numbers, but I'm not sure.
>
> It would be nice to hear what Heikki's reasons were for adding
> PD_ALL_VISIBLE in the first place.

The idea was to avoid clearing the bit in the VM page on every update, 
when the bit is known to not be set, ie. when the PD_ALL_VISIBLE flag is 
not set. I assumed the traffic and contention on the VM page would be a 
killer otherwise. I don't remember if I ever actually tested that 
though. Maybe I was worrying about nothing and hitting the VM page on 
every update is ok.

- Heikki



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Teaching pg_receivexlog to follow timeline switches
Next
From: Heikki Linnakangas
Date:
Subject: Re: Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave