Re: Set visibility map bit after HOT prune
Jeff Janes <jeff.janes@gmail.com>
From: Jeff Janes <jeff.janes@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Pavan Deolasee <pavan.deolasee@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2012-12-21T02:24:00Z
Lists: 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 <javascript:;>> 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