Re: Removing PD_ALL_VISIBLE

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Removing PD_ALL_VISIBLE
Date: 2013-01-21 02:05:53
Message-ID: CA+TgmoZVX9tQ9pGOKupwsqLUAswjKydv8APEhr-edGDxppjunw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 18, 2013 at 3:31 AM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> So, I attached a new version of the patch that doesn't look at the VM
> for tables with fewer than 32 pages. That's the only change.

That certainly seems worthwhile, but I still don't want to get rid of
this code. I'm just not seeing a reason why that's something that
desperately needs to be done. I don't think this is a barrier to
anything else we want to do, and it might well be that the situations
where this patch would hurt us are currently masked by other
bottlenecks, but won't be always. Right now, the vast majority of
heap updates don't need to pin the visibility map page; with this
change, all of them do. Now, I accept that your test results show
that that doesn't matter, but how can that not be an artifact of some
kind? Can we really credit that accessing two pages costs no more
than accessing one? To what countervailing factor could we plausibly
attribute that?

Now, even if it costs more in some narrow sense, the difference might
not be enough to matter. But without some big gain on the other side,
why tinker with it?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2013-01-21 02:18:04 Re: How to build contrib module separately in PostgreSQL on windows
Previous Message Craig Ringer 2013-01-21 02:05:44 Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]