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: CAMkU=1xyG=22ZRWqpSPcOhq2gD9YDY3eFN1dF3csK0cAKbRUKw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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?

Yes.

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

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

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

Cheers,

Jeff

In response to

Browse pgsql-hackers by date

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