Re: Set visibility map bit after HOT prune - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Set visibility map bit after HOT prune
Date
Msg-id CAMkU=1xYTKNxG7jY9rJCzq+JWO7VgbC55EJzXks_Q-Vf5xQxKg@mail.gmail.com
Whole thread Raw
In response to Re: Set visibility map bit after HOT prune  (Robert Haas <robertmhaas@gmail.com>)
Responses Set visibility map bit after HOT prune  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers


On Wednesday, December 19, 2012, Robert Haas wrote:
On Wed, Dec 19, 2012 at 12:26 PM, Pavan Deolasee
<pavan.deolasee@gmail.com> wrote:

> I would like to run some pgbench tests where we get the system in a
> steady state such as all/most updates are HOT updates (not entirely
> unlikely scenario for many real life cases). And then try running some
> concurrent queries which can be executed via IOS. My gut feel is that,
> today we will see slow and continuous drop in performance for these
> queries because IOS will slowly stop working.

If there are no vacuums, I agree.

If the table is randomly updated over its entire size, then pretty much every block will be not-all-visible (and so disqualified from IOS) before you hit the default 20% vacuum threshold.  I wonder if there ought not be another vac threshold, based on vm density rather than estimated obsolete tuple density.
 
Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Review of Row Level Security
Next
From: Jeff Janes
Date:
Subject: Set visibility map bit after HOT prune