Skip site navigation (1) Skip section navigation (2)

Re: Do we need so many hint bits?

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
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-18 05:24:02
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Nov 16, 2012 at 5:35 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> On Fri, 2012-11-16 at 17:04 -0800, Jeff Janes wrote:

>> 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.

The benefit would be that index only scans would be more likely to not
need to visit the heap page, if it only had HOT updates done to it
since the last time it was all-visible.

Also some reduced vacuuming, but I don't know if that benefit would be

> 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

Right, but if the HOT-only bit was on the page itself, it would no
longer help out index-only-scans.



In response to

pgsql-hackers by date

Next:From: C├ędric VillemainDate: 2012-11-18 09:52:24
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL
Previous:From: Steve SingerDate: 2012-11-18 03:50:35
Subject: Re: logical changeset generation v3 - Source for Slony

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group