Re: Removing PD_ALL_VISIBLE - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Removing PD_ALL_VISIBLE
Date
Msg-id CA+TgmoZVX9tQ9pGOKupwsqLUAswjKydv8APEhr-edGDxppjunw@mail.gmail.com
Whole thread Raw
In response to Re: Removing PD_ALL_VISIBLE  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Removing PD_ALL_VISIBLE
List pgsql-hackers
On Fri, Jan 18, 2013 at 3:31 AM, Jeff Davis <pgsql@j-davis.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



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]
Next
From: Craig Ringer
Date:
Subject: Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]