On 17.01.2013 16:53, Robert Haas wrote:
> On Thu, Jan 17, 2013 at 3:49 AM, Pavan Deolasee
> <pavan(dot)deolasee(at)gmail(dot)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.
In response to
pgsql-hackers by date
|Next:||From: Heikki Linnakangas||Date: 2013-01-17 15:18:14|
|Subject: Re: Re: Slave enters in recovery and promotes when WAL
stream with master is cut + delay master/slave|
|Previous:||From: Robert Haas||Date: 2013-01-17 15:12:09|
|Subject: Re: Teaching pg_receivexlog to follow timeline switches|