Skip site navigation (1) Skip section navigation (2)

Re: Removing PD_ALL_VISIBLE

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Removing PD_ALL_VISIBLE
Date: 2013-01-17 15:14:04
Message-ID: 50F8153C.6020300@vmware.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

- Heikki


In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 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 HaasDate: 2013-01-17 15:12:09
Subject: Re: Teaching pg_receivexlog to follow timeline switches

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group