On Mon, Feb  3, 2014 at 11:55:34AM -0500, Robert Haas wrote:
> > Robert, where are we on this?  Should I post a patch?
> I started working on this at one point but didn't finish the
> implementation, let alone the no-doubt-onerous performance testing
> that will be needed to validate whatever we come up with.  It would be
> really easy to cause serious regressions with ill-considered changes
> in this area, and I don't think many people here have the bandwidth
> for a detailed study of all the different workloads that might be
> affected here right this very minute.  More generally, you're sending
> all these pings three weeks after the deadline for CF4.  I don't think
> that's a good time to encourage people to *start* revising old
> patches, or writing new ones.
> I've also had some further thoughts about the right way to drive
> vacuum scheduling.  I think what we need to do is tightly couple the

I understand the problems with vacuum scheduling, but I was trying to
address _just_ the insert-only workload problem for index-only scans.

Right now, as I remember, only vacuum sets the visibility bits.  If we
don't want to make vacuum trigger for insert-only workloads, can we set
pages all-visible more often?  

Is there a reason that a sequential scan, which does do page pruning,
doesn't set the visibility bits too?  Or does it?  Can an non-index-only
index scan that finds the heap tuple all-visible and the page not 
all-visible check the other items on the page to see if the page can be
marked all-visible?  Does analyze set pages all-visible?

  Bruce Momjian  <br...@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + Everyone has their own god. +

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to