On Fri, 2012-11-16 at 17:04 -0800, Jeff Janes wrote:
> On Thu, Nov 15, 2012 at 4:42 PM, Jeff Davis <pgsql@j-davis.com> wrote:
> >
> > 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? It can be used for the scan
> > because it is crash safe now (not possible before). And since it's only
> > one lookup per scanned page,
>
> Wouldn't you need to lock two pages simultaneously, for each table
> page, in order to ensure that there are no races?
>
> For a full table scan, that might not be so good.
Can you explain? The table scan share locks the heap page during the
visibility check (which should suffice as a memory barrier) and then
could test the VM bit with only a pin on the VM page.
> Your question prompts me to post something I had been wondering.
> Might it be worthwhile to break the PD_ALL_VISIBLE / vm equivalence?
> Should the vm bit get cleared by a HOT update?
To clarify: are you saying that a hot update should clear the
PD_ALL_VISIBLE bit, but not the VM bit?
> And anyone can vacuum a block that has only had HOT updates, you don't
> need to be dedicated vacuum worker to do that.
> And obviously this would be incompatible with removing the
> PD_ALL_VISIBLE, unless we also wanted to eliminate the ability to
> short-cut hint bit checks.
I'm still a little unclear on what the benefit is.
It sounds like a slightly different kind of hint, so maybe we should
just treat it as a completely different thing after removing
PD_ALL_VISIBLE. If it's related to HOT updates, then the page will
probably be dirty anyway, so that removes my primary complaint about
PD_ALL_VISIBLE.
Regards,Jeff Davis
