Re: Do we need so many hint bits?

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, Merlin Moncure <mmoncure(at)gmail(dot)com>
Subject: Re: Do we need so many hint bits?
Date: 2012-11-16 06:44:23
Message-ID: 1353048263.10198.11.camel@jdavis-laptop
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2012-11-15 at 22:21 -0500, Tom Lane wrote:
> We aren't pressed for flag bits particularly. I think the main
> attraction of this idea is precisely to reduce unnecessary page dirties,
> and so that leads me to suggest a variant: keep the four bits defined as
> now, but do not attempt to set XMIN_INVALID or XMAX_COMMITTED unless the
> page is already dirty. This would make it a straight-up trade of more
> clog consultation for fewer page dirties.

Sounds reasonable.

> > Also, I am wondering about PD_ALL_VISIBLE. It was originally introduced
> > in the visibility map patch, apparently as a way to know when to clear
> > the VM bit when doing an update. It was then also used for scans, which
> > showed a significant speedup. But I wonder: why not just use the
> > visibilitymap directly from those places?
>
> Added contention for access to the visibility map pages would be a
> problem.

Can you think of a reasonable (or worst-case) test scenario that would
illustrate this problem? Would I need a many-core box to actually test
this?

Also, what locks do you expect to be contended? The buffer header lock
while pinning the VM page?

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2012-11-16 06:49:44 Re: [PATCH] binary heap implementation
Previous Message Pavel Stehule 2012-11-16 06:21:11 Re: gset updated patch