| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2013-01-17 15:18:14 | Re: Re: Slave enters in recovery and promotes when WAL stream with master is cut + delay master/slave |
| Previous Message | Robert Haas | 2013-01-17 15:12:09 | Re: Teaching pg_receivexlog to follow timeline switches |