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


From: Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Removing PD_ALL_VISIBLE
Date: 2013-01-17 09:27:13
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
At 2013-01-17 08:41:37 +0000, simon(at)2ndQuadrant(dot)com wrote:
> Jeff, can you summarise/collate why we're doing this, what concerns it
> raises and how you've dealt with them?

Since I was just looking at the original patch and discussion, and since
Pavan has posted an excerpt from one objection to it, here's an excerpt
from Jeff's original post titled "Do we need so many hint bits?"

    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, then I
    don't think it would be a measurable performance loss there.
    Inserts/updates/deletes also do a significant amount of work, so
    again, I doubt it's a big drop in performance there -- maybe under a
    lot of concurrency or something.

    The benefit of removing PD_ALL_VISIBLE would be significantly
    higher. It's quite common to load a lot of data, and then do some
    reads for a while (setting hint bits and flushing them to disk), and
    then do a VACUUM a while later, setting PD_ALL_VISIBLE and writing
    all of the pages again. Also, if I remember correctly, Robert went
    to significant effort when making the VM crash-safe to keep the
    PD_ALL_VISIBLE and VM bits consistent. Maybe this was all discussed

There was considerable discussion after this (accessible through the
archives link above), which I won't attempt to summarise.

-- Abhijit

In response to


pgsql-hackers by date

Next:From: Magnus HaganderDate: 2013-01-17 09:36:47
Subject: Re: review: pgbench - aggregation of info written into log
Previous:From: Magnus HaganderDate: 2013-01-17 09:22:48
Subject: Re: CF3+4 (was Re: Parallel query execution)

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